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for  mission  accomplishment  within  the  Department  of 
Defense,  the  rules  for  protecting  information  have 
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information  technology  in  the  21st  century  dictates  the 
adoption  of  a  flexible  and  adaptable  cryptographic  strategy 
for  protecting  national  security  information.  RSA 
techniques,  while  formidable,  have  begun  to  present 
vulnerabilities  to  the  raw  computing  power  that  is 
commercially  available  today. 

This  thesis  is  a  comprehensive  characterization  of  the 
current  state  of  the  art  in  DoD  encryption  standards.  It 
will  emphasize  the  mathematical  algorithms  that  facilitate 
legacy  encryption  and  its  proposed  NSA  Suite  B 
replacements.  We  will  look  at  how  the  new  technology 
addresses  the  latest  threats  and  vulnerabilities  that 
legacy  methods  do  not  fully  mitigate.  It  will  then 
summarize  the  findings  of  the  security  capabilities  of  NSA 
Suite  B  standards  as  compared  to  the  costs  in  manpower  and 
money  to  implement  them,  and  suggest  how  to  best  utilize 
NSA  Suite  B  technology  for  the  purpose  of  providing 
confidentiality,  integrity  and  availability  in  an 
environment  with  real  world  threats. 
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I .  INTRODUCTION 


A.  MOTIVATION  FOR  THESIS 

In  August  2001 ,  the  National  Institute  of  Standards 
and  Technology  (NIST)  issued  the  SP  800-78-1  publication  on 
Information  Security.  SP  800-78-1  specifies  the  timeline 
for  mandatory  Public  Key  Infrastructure  (PKI)  cryptographic 
key  and  hash  migration  for  the  next  several  years.  This 
standard  stipulates  the  implementation  deadlines  for 
several  Personal  Identification  Verification  (PIV)  related 
cryptographic  changes  such  as  new  algorithms  and  larger  key 
and  hash  sizes.  Each  cryptographic  change  in  Common  Access 
Card  (CAC)  and  Certificate  Authority  (CA)  key  size,  key 
algorithms,  and  hash  size  has  the  potential  to  push 
issuance  and  usage  times  beyond  acceptable  limits  for  the 
average  Department  of  Defense  (DoD)  user. 

This  thesis  will  determine  some  of  the  potential 
impact  of  this  migration  on  CAC  usage.  It  will  describe 
findings  obtained  through  lab  testing  of  CAC  cards  using 
old  and  new  encryption  techniques  and  will  assess  some  of 
the  risk  associated  with  a  DoD-wide  migration  to  RSA  2048 
with  SHA-1  keys  and  eventually  to  NSA  Suite  B.  Migration 
risk  will  be  analyzed  and  quantified  using  a  critical  path 
analysis  technique. 

The  motivation  for  this  research  is  to  help  identify 
to  the  federal  community  some  prudent  testing  and  some 
potentially  important  milestones  for  each  of  the  proposed 
cryptographic  changes.  In  order  to  do  this  we  will  focus 
on  issues  of  performance  and  risk  management. 
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B.  CURRENT  STATE  OF  DOD  CAC  METHODS  AND  PROCEDURES 

The  Department  of  Defense  has  approximately  four 
million  CAC  cards  in  active  circulation.  Use  of  these 
cards  is  mandatory  for  PKI,  DoD-wide  interoperable  access 
to  systems,  and  physical  access  to  government  intranet 
sites.  The  degrees  of  freedom  in  this  PKI  system  are  very 
low,  and  any  disruptions  are  likely  to  have  significant  and 
potentially  long  lasting  repercussions.  Hence,  a  change  in 
any  part  of  the  CAC  system  must  be  tested  carefully  and 
meticulously  prior  to  entering  final  production.  SP  800- 
78-1  specifies  a  number  of  cryptographic  enhancements  and 
the  time  line  for  their  implementation.  These  include  a 
substantial  increase  in  RSA  key  size  from  1024  to  2048 
bits,  transition  from  SHA  1  to  SHA  256,  continuation  of  the 
use  of  the  AES  symmetric  algorithm  and  eventually 
transition  to  components  of  NSA  Suite  B. 

C.  SCOPE 

The  CAC  testing  procedures  assume  proper  functionality 
of  all  tested  algorithms  and  so  focus  instead  on 
performance,  although  observation  of  both  aspects  will 
occur  in  this  thesis.  Testing  is  divided  into  two  parts. 
Part  one  is  a  comparison  of  1024-  and  2048-bit  RSA  key 
generation  and  Secure  Sockets  Layer  (SSL)  authentication. 
Part  two  compares  the  same  metrics  for  RSA  1024  as  they 
match  up  against  ECC  256. 

The  recommended  testing  is  not  meant  to  be  exhaustive 
but  rather  to  indicate  possible  performance  constraints. 
The  DoD  PIV  End  Point  CAC  performs  three  RSA  key 
generations  inside  of  the  smart  card  for  total  security 
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assurance.  This  paper  includes  detailed  statistical 
information  on  the  difference  between  the  1024-bit  keys  and 
2048-bit  keys. 

D .  ENCRYPTION  TAXONOMY 

The  modern  field  of  cryptography  includes 
authentication,  integrity,  confidentiality  and  non¬ 
repudiation  of  information.  Some  older  cryptographic 

methods  rely  on  the  secrecy  of  their  encryption  algorithms. 
Most  modern  algorithms  base  their  security  on  the  security 
of  keys  rather  than  the  secrecy  of  the  method.  Most  modern 
techniques  fall  into  one  of  two  types:  symmetric  and 
asymmetric . 

Symmetric  key  cryptography  uses  a  single  key  for  both 
encryption  and  decryption.  With  symmetric  key 

cryptography,  the  key  must  be  known  to  both  the  sender  and 
the  receiver.  The  most  significant  challenge  to  this 
method  then  becomes  the  distribution  and  management  of 
these  keys.  If  there  are  100  people  who  need  to 

communicate  with  one  another,  each  one  of  them  needs  to 

share  a  common  secret  key  with  the  other  99.  The 
implication  of  this  is  that  all  100  people  have  to  keep  all 
keys  safe,  which  creates  a  challenging  security  situation. 

Asymmetric  key  cryptography,  or  public  key 

cryptography,  came  about  in  part  to  address  the  key 

management  issues  created  by  use  of  symmetric  key 

cryptography.  Instead  of  a  single,  secret  key  for  each 

pair  of  users,  asymmetric  key  cryptography  requires  a 

private  and  a  public  key  for  each  participating  user.  The 

public  key,  which  is  used  for  the  encryption  of  the 

message,  is  freely  distributable.  The  private  key  is  used 
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only  to  decrypt  the  message.  Since  the  private  key  cannot 
be  computed  based  solely  on  the  knowledge  of  the  public 
key,  the  system  remains  secure  even  though  the  public  key 
is  freely  available.  In  this  scenario,  every  user  needs 

only  keep  his  or  her  private  key  confidential.  An  added 
benefit  of  this  method  is  that  it  facilitates  a  method  for 
generating  digital  signatures  for  authentication  and  non¬ 
repudiation  . 

Symmetric  algorithms  are  generally  much  faster  to 

execute  than  asymmetric.  However,  asymmetric  algorithms 
are  roughly  100  to  1,000  times  more  difficult  to  break 
depending  on  the  algorithm  (De  Clercq,  2006)  .  In  broad 
security  practice,  symmetric  and  asymmetric  algorithms  are 
used  together  so  that  an  asymmetric  key  algorithm  can  be 

used  to  exchange  a  randomly  generated  symmetric  key.  The 
generated  symmetric  key  can  then  be  used  to  encrypt  the 
actual  message  using  a  symmetric  algorithm.  Following  from 
this  idea,  asymmetric  ciphers  are  typically  used  for  data 
authentication  through  digital  signatures,  for  the 
distribution  of  a  symmetric  bulk  encryption  key,  for  non¬ 
repudiation  services,  and  for  key  agreement.  Symmetric 
ciphers  support  the  secure  exchange  of  information 

synergistically  with  asymmetric  algorithms  by  bulk 
encrypting  the  actual  data. 
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II.  RIVEST  SHAMIR  ADLEMAN  (RSA)  ALGORITHM 


A.  INTRODUCTION 

1.  History  of  RSA  Algorithm  Based  Encryption 

The  RSA  algorithm,  initially  published  in  the  paper  "A 
Method  for  Obtaining  Digital  Signatures  and  Public-Key 
Cryptosystems"  in  1977  is  the  product  of  the  combined 
efforts  of  Ron  Rivest,  Adi  Shamir  and  Len  Adleman.  Named 
after  the  first  initials  of  the  MIT  researchers  last  names, 
the  RSA  algorithm  can  be  used  for  both  public  key 

encryption  and  digital  signatures.  Its  security  is  based 
on  the  difficulty  of  factoring  large  prime  integers.  RSAs 
breakthrough  became  widely  publicized  by  Martin  Gardner  in 
August  1977,  in  his  column  "Mathematical  Games"  in 
Scientific  American  magazine.  At  the  time,  the  authors 

offered  to  send  their  full  report  to  anyone  who  sent  them  a 
self-addressed  stamped  envelope.  In  spite  of  attempts  by 
the  NSA  to  stop  the  international  distribution  of  the  RSA 
source  code  it  continued  due  to  lack  of  a  legal  basis  for 
the  NSAs  request.  A  more  detailed  version  was  subsequently 
published  in  the  February  1978  edition  of  The 
Communications  of  the  ACM  thereby  rendering  all  protests 
moot.  Regardless,  the  legal  battle  with  the  U.S. 

Government  over  the  RSA  algorithm  went  on  for  several 
years.  Finally,  in  1982,  Rivest,  Shamir  and  Adleman  formed 
the  company  "RSA"  to  market  their  Public  Key  Cryptography 
(PKC)  algorithm  as  an  electronic  security  product.  They 
obtained  a  patent  on  the  RSA  algorithm  in  the  U.S.  only. 
They  could  not  obtain  an  international  patent  because  they 
had  already  published  their  ideas  globally  and  most 
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countries  bar  retroactive  patenting  of  open  source 
concepts.  In  September  2000,  the  U.S.  patent  for  the  RSA 
algorithm  expired,  enabling  software  developers  everywhere 
to  freely  include  this  PKC  standard  in  their  products 
(Stewart,  2009) . 

Whether  as  a  licensed  product,  (e.g.,  part  of  Pretty 
Good  Privacy)  ,  or  implemented  for  private  use,  the  RSA 
algorithm  has  become  the  foundation  of  an  entire  generation 
of  public  key  cryptography  security  products.  It  provides 
secure  communications  between  parties  separated  by  distance 
that  may  have  never  met.  RSA  provides  the  ideal  mechanism 
required  for  private  communications  over  distributed 
electronic  networks,  and  forms  the  basis  of  almost  all  the 
security  products  now  in  use  on  the  Internet  for  financial 
and  other  private  communications,  including  most  enterprise 
level  Public  Key  Infrastructure  (PKI)  systems,  like  that 
operated  by  the  Department  of  Defense. 

B.  UNDERLYING  CONCEPTS  AND  TECHNOLOGY 

1 .  Key  Generation 

In  order  to  generate  the  necessary  keys  to  support  RSA 
cryptographic  operations,  the  following  algorithm  is 
required.  Two  large,  random  prime  numbers  must  be 
generated,  p  and  q,  of  approximately  equal  size  such  that 
their  product,  n,  is  of  the  required  bit  length.  The  size 
of  an  RSA  key  refers  to  the  bit-length  of  the  RSA  modulus. 
This  should  not  be  confused  with  the  actual  number  of  bits 
required  to  store  an  RSA  public  key,  which  may  be  slightly 
more  (Lenstra  &  Verheul,  p.  8)  .  The  topic  of  key  lengths 
and  their  associated  strengths  will  be  looked  at  in  Chapter 
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Ill  of  this  thesis,  but  in  general  the  larger  the  prime 
numbers,  the  stronger  the  generated  key. 

Next,  compute  n  =  pq  and  compute  cp  =  (p-1)  (q-1)  .  The 
value  of  n  is  known  as  the  modulus.  The  value  of  phi  is 
the  lower  limit  of  the  boundary  in  which  the  set  of  numbers 
that  are  co-prime  to  n  is  contained.  The  upper  limit  is  n 
itself . 

Third,  choose  an  integer  e  such  that  1  <  e  <  cp,  and 
such  that  the  greatest  common  divisor  (gcd)  of  e  and  cp  is 
1.  The  value  chosen  for  e  is  known  as  the  public  exponent 
or  encryption  exponent  or  just  simply  the  exponent. 

Finally,  Compute  the  secret  exponent  d,  1  <  d  <  cp, 

such  that  (e)  (d)  =  1  (mod  cp)  .  In  order  to  compute  the 

value  for  d,  the  Extended  Euclidean  Algorithm  must  be  used 
to  calculate  d  =  e~^  (mod  cp)  .  The  Extended  Euclidean 

Algorithm  is  used  in  mathematics  for  finding  the  gcd  of  any 
two  integers.  The  computed  d  value  is  known  as  the  secret 
exponent  or  decryption  exponent. 

The  public  key  now  becomes  (n,  e)  and  the  private  key, 
(n,  d)  .  All  the  values  d,  p,  q  and  cp  must  be  kept  secret. 
In  practice,  common  choices  for  e  are  3,  17  and  65537 
(2^®+l) .  These  are  Fermat  primes,  sometimes  referred  to  as 
FO,  F2  and  F4  respectively.  The  formula  used  to  derive 
numbers  from  the  Fermat  sequence  is  F  (x)  =2^^  (2''x) +1)  .  They 
are  chosen  because  they  make  the  modular  exponentiation 
operation  faster.  Also,  having  chosen  e,  it  is  simpler  to 
test  whether  gcd(e,  p-l)=l  and  gcd(e,  q-l)=l  while 
generating  and  testing  the  primes  in  the  first  step. 
Values  of  p  or  q  that  fail  this  test  can  be  rejected 
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without  further  consideration.  Once  keys  have  been 

generated,  encryption  and  decryption  becomes  a  relatively 
simple  mathematical  process. 

2 .  Encryption 

Once  a  key  of  appropriate  length  has  been  generated  it 
next  falls  to  the  process  of  encrypting  the  plaintext 
message.  In  order  to  encrypt,  the  sender  must  do  the 
following : 

1.  Obtain  the  recipients  public  key. 

2.  Represent  the  plaintext  message  as  a  positive 

integer  m. 

3.  Compute  the  cipher-text  c  =  m®  (mod  n)  . 

4.  Send  the  cipher-text  c  to  the  recipient. 

3 .  Decryption 

In  order  to  decrypt  the  message,  the  recipient  must  do 
the  following: 

1.  Use  their  private  key  to  compute  m  =  c*^  (mod  n)  . 

2.  Extract  the  plaintext  from  the  message 
representative  m. 

4 .  Key  Management 

Anyone  who  wishes  to  sign  a  message  or  decrypt  an 
encrypted  message  must  have  a  key  pair.  It  is  common  to 
use  separate  key  pairs  for  signing  messages  and  encrypting 
messages.  Additionally,  a  user  could  have  a  key  pair 
affiliated  with  his  or  her  work  and  a  separate  key  pair  for 
personal  use.  Other  entities  may  also  have  key  pairs, 

including  electronic  devices  such  as  modems,  workstations, 
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Web  servers  (Web  sites)  and  printers,  as  well  as 
organizational  entities  such  as  a  corporate  department,  a 
hotel  registration  desk,  or  a  university  registrars  office. 
Key  pairs  allow  people  and  other  entities  to  authenticate 
and  encrypt  messages.  (RSA  Security,  2000,  p.  4.1.1) 

A  user  can  generate  his  or  her  own  key  pair,  or, 
depending  on  local  policy,  a  security  officer  may  generate 
key  pairs  for  all  users.  There  are  tradeoffs  between  the 
two  approaches.  In  the  former,  the  user  needs  some  way  to 
trust  his  or  her  copy  of  the  key  generation  software,  and 
in  the  latter,  the  user  must  trust  the  security  officer  and 
the  private  key  must  be  transferred  securely  to  the  user. 
Typically,  each  node  on  a  network  would  be  capable  of  local 
key  generation. 

Once  a  key  has  been  generated,  the  user  must  register 
his  or  her  public  key  with  some  central  administration, 
called  a  Certification  Authority.  The  CA  returns  to  the 
user  a  certificate  attesting  to  the  "binding"  of  the  users 
public  key  to  certain  user  attributes;  the  users  unique 
name/identity  being  one  typical  attribute.  If  a  security 
officer  generates  the  key  pair,  then  the  security  officer 
can  request  the  certification  of  the  public  key  on  behalf 
of  the  user. 

As  with  all  keys,  distribution  is  important  to 
security.  Key  distribution  must  be  secured  against 

observation  (unauthorized  disclosure)  ,  modification  (a  loss 
of  integrity)  and  impersonation  (a  loss  of  authenticity) . 


If  an  attacker  has 

a  way  to 

give 

a  legitimate  user 

an 

arbitrary  key  that 

will 

make 

him 

believe  it  belongs 

to 

another  legitimate 

user. 

and 

the 

attacker  can  intercept 
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transmissions  between  two  legitimate  users,  then  they  can 
send  their  own  public  key  (which  is  believed  to  belong  to  a 
legitimate  user)  and  intercept  any  real  cipher-text  sent. 
Once  intercepted  the  encrypted  message  can  be  decrypted 
with  the  attackers  own  private  key,  a  copy  of  the  message 
can  be  saved,  the  message  can  be  re-encrypted  with  a 
legitimate  public  key,  and  the  new  cipher-text  can  be  sent 
to  the  intended  legitimate  recipient.  In  principle, 
neither  legitimate  user  would  be  able  to  detect  the 
activities  of  the  attacker.  Defenses  against  such  attacks 
are  often  based  on  digital  certificates  or  other  components 
of  a  public  key  infrastructure. 

C.  SECURITY  CONSIDERATIONS 

Factoring  an  RSA-modulus,  n,  by  exhaustive  search 
amounts  to  trying  all  primes  up  to  the  product  of  p  and  n. 
Finding  a  discrete  logarithm  by  exhaustive  search  requires 
on  the  order  of  p  operations  in  a  finite  field  of  numbers 
as  large  as  p  itself.  If  exhaustive  search  were  the  best 
attack  on  these  systems,  then  bit  length  could  be 
relatively  small  with  an  acceptable  level  of  security. 
However,  there  are  much  more  efficient  and  creative  attacks 
available  to  attackers.  Such  attacks  can  only  be  defeated 
by  the  use  of  much  larger  keys,  which  will  help  to  maintain 
acceptable  security.  The  most  efficient  factoring 
algorithm  published  to  date  is  the  Number  Field  Sieve, 
invented  in  1988  by  John  Pollard.  Originally,  it  could  be 
used  only  to  factor  numbers  of  a  special  form,  such  as  the 
ninth  Fermat  number  2512  +  1.  This  original  version  is 
currently  referred  to  as  the  Special  Number  Field  Sieve 
(SNFS) ,  as  opposed  to  the  General  Number  Field  Sieve 


10 


(GNFS) ,  which  can  handle  numbers  of  arbitrary  form, 
including  RSA  moduli.  Heuristically  the  GNFS  can  be 
expected  to  require  time  proportional  to 

g  (1 . 922  9+0(1)  )  In  (n)  l/31n  (In  (n)  )  2/3 

to  factor  an  RSA  modulus  n,  where  the  o(l)  term  goes  to 
zero  as  n  goes  to  infinity.  (Lenstra  &  Verheul,  p.9-10) 

1 .  RSA  Integer  Factorization 

As  previously  stated,  the  RSA  factoring  problem  is  the 
task  of  taking  eth  roots  modulo  a  composite  n:  recovering  a 
value  m  such  that  c  =  m®mod  n,  where  (n,e)  is  an  RSA  public 
key  and  c  is  an  RSA  encrypted  message.  The  simplest  and 
most  direct  approach  to  solving  the  RSA  problem  is  to 

factor  the  modulus.  With  the  ability  to  recover  its  prime 
factors,  an  attacker  can  compute  the  secret  exponent  d  from 
a  public  key  (n,e),  then  decrypt  c  using  the  standard 
procedure.  To  accomplish  this,  an  attacker  factors  n  into 
p  and  q,  and  computes  (p  -  1)  (q  -  1),  which  then  allows  d 

to  be  determined  from  e.  No  set  number  of  computational 

steps  for  factoring  large  integers  on  a  classical  computer 
has  yet  been  found,  however  the  absence  of  evidence  is  not 
definitive  evidence  of  absence.  It  has  not  been  proven 
that  no  polynomial-time  method  exists  to  solve  the 

algorithm,  outright. 

As  of  2008,  the  largest  number  factored  by  a  general- 
purpose  factoring  algorithm  was  663  bits  long  (RSA-200)  , 
using  a  state-of-the-art  distributed  implementation.  The 
next  largest  number  is  probably  going  to  be  a  768-bit 
modulus  according  to  Peter  Montgomery  in  his  October  2008 
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publication  on  Preliminary  Design  of  Post-Sieving 
Processing  for  RSA-768.  (Montgomery,  2008) 

NIST  recommends  RSA  keys  to  be  at  least  1,024  bits 
with  a  near  term  increase  to  2048  bits  long.  With 
increased  computing  power  now  commercially  available, 
1,024-bit  keys  may  become  breakable  in  the  foreseeable 
future,  and  will  be  considered  insufficiently  secure  in  the 
year  2010. 

As  previously  stated,  the  strength  of  RSA  encryption 
is  based  on  key  size.  The  bigger  the  key,  the  better 
security  it  provides.  If  the  key  length,  n,  is  300  or 
fewer  bits,  it  can  be  factored  in  a  few  hours  on  a  personal 
computer  with  average  processing  capability,  using  software 
already  freely  available.  In  1999,  keys  of  512-bit  length 
were  shown  to  be  breakable  when  RSA-155  was  factored  by 
using  several  hundred  computers.  Since  that  time,  512-bit 
length  keys  have  been  demonstrated  to  be  vulnerable  to 
factoring  using  commonly  available  hardware  in  as  little 
time  as  a  few  weeks.  (Fivemack,  2007) 

2 .  Timing  Attacks 

In  1995,  President  and  Chief  Scientist  of  Cryptography 
Research  Inc.,  Paul  Kocher,  described  a  new  way  to  attack 
the  RSA  algorithm.  If  an  attacker  knows  the  legitimate 
users  hardware  in  sufficient  detail  and  is  able  to  measure 
the  decryption  times  for  several  known  cipher-texts,  he  can 
deduce  the  decryption  key  quickly.  This  attack  can  be 
applied  against  the  RSA  signature  scheme  as  well.  In  2003, 
a  more  practical  attack  capable  of  recovering  RSA 
factorizations  over  a  network  connection  (e.g.,  from  a  SSL- 


enabled  Web  server)  was  found.  This  attack  took  advantage 
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of  a  weakness  in  the  Chinese  Remainder  Theorem  (CRT) 
optimization  used  by  many  RSA  implementations. 

One  way  to  defeat  timing  attacks  is  to  ensure  that  the 
decryption  operation  takes  a  constant  amount  of  time  for 
every  key.  However,  this  approach  can  significantly  reduce 
performance.  Instead,  most  RSA  implementations  use  an 
alternate  technique  known  as  cryptographic  blinding. 
Blinding  makes  use  of  the  multiplicative  property  of  RSA. 
Instead  of  computing  c'^mod  n,  the  legitimate  user  first 
chooses  a  secret  random  value  r  and  computes  (r®c)‘^mod  n. 
The  result  of  this  computation  is  rm(mod  n)  and  so  the 
effect  of  r  can  be  removed  by  multiplying  by  its  inverse.  A 
new  value  of  r  is  chosen  for  each  cipher-text.  With 
blinding  applied,  the  decryption  time  is  no  longer 
correlated  to  the  value  of  the  input  cipher-text  and  so  the 
timing  attack  fails  (Kocher,  n.d.). 

3.  Chosen  Cipher-text  Attacks 

A  chosen  cipher-text  attack  (CCA)  is  an  attack  model 
in  which  the  cryptanalyst  gathers  information  by  choosing  a 
cipher-text  and  decrypting  it  without  previously  knowing 
the  key. 

A  number  of  seemingly  secure  schemes  can  be  defeated 
by  chosen  cipher-text  attacks.  Early  versions  of  RSA 
padding  (padding  will  be  addressed  in  more  depth  later  in 
this  chapter)  used  in  the  SSL  protocol  were  vulnerable  to  a 
particular  adaptive  chosen  cipher-text  attack,  which 
revealed  SSL  session  keys.  Due  to  flaws  within  the  padding 
scheme,  a  practical  attack  against  RSA  implementations  of 
the  SSL  protocol  was  found.  As  a  result,  cryptographers 


now  recommend  the  use  of  provably  secure  padding  schemes 
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such  as  Optimal  Asymmetric  Encryption  Padding. 
Additionally,  RSA  Laboratories  has  released  new  versions 
that  are  not  vulnerable  to  chosen  cipher-text  attacks . 
(Cramer  &  Shoup,  1998) 

CCAs  have  implications  for  designers  of  tamper- 
resistant  cryptographic  smart  cards  as  well.  They  must  be 
particularly  cognizant  of  the  CCA  threat,  as  these  cards 
could  conceivably  fall  into  the  hands  of  an  unauthorized 
user,  who  might  then  issue  a  large  number  of  chosen  cipher- 
texts  in  an  attempt  to  recover  the  hidden  secret  key. 

When  a  cryptosystem  is  vulnerable  to  chosen  cipher- 
text  attacks,  its  implementers  must  be  careful  to  avoid 
situations  in  which  an  attacker  might  be  able  to  decrypt 
chosen  cipher-texts.  Specifically,  the  explicit 

requirement  of  a  message  integrity  checker  and  the  use  of 
some  form  of  message  compression  will  offer  protection 
against  chosen  cipher-text  attacks.  (Jallad,  Katz  & 
Schneier,  2003,  p.l2) 

Chosen  cipher-text  attacks  may  be  adaptive  or  non- 
adaptive.  In  a  non-adaptive  attack,  the  attacker  chooses 
the  cipher-text  to  be  decrypted  in  advance,  and  does  not 
use  the  resulting  plain-text  message  to  influence  their 
next  cipher-text  target.  In  an  adaptively  chosen  cipher- 
text  attack,  the  attacker  makes  their  target  message  choice 
adaptively,  that  is,  the  message  to  be  decrypted  is  chosen 
based  on  the  results  of  all  prior  decryptions.  (Cramer  & 
Shoup,  1998) 
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4. 


Branch  Prediction  Analysis  Attacks 


Branch  prediction  analysis,  also  called  BPA,  uses  a 
branch  predictor  to  determine  whether  a  conditional  branch 
in  the  instruction  flow  of  a  program  is  likely  to  be  taken. 
Typical  branch  prediction  analysis  attacks  use  a  spy 
process  to  statistically  discover  a  private  key  when  it  is 
used  to  encrypt  data.  A  more  refined  form  of  BPS  known  as 
Simple  Branch  Prediction  Analysis  (SBPA)  claims  to  improve 
BPA  in  a  way  that  is  less  calculation  intensive  but  far 
more  insidious  and  efficient.  (Aciicmez,  Koc  &  Seiffert, 
2007) 

While  BPA  attacks  resemble  timing  attacks,  where  an 
attacker  uses  many  execution-time  measurements  under  the 
same  key  in  order  to  statistically  amplify  some  small  but 
key  dependent  timing  differences,  SBPA  dramatically 
improves  upon  standard  BPA  results.  Using  a  spy  process 
that  runs  simultaneously  with  an  RSA-process,  collection  of 
almost  all  the  secret  key  bits  is  possible  during  an  RSA 
signing  execution.  Using  SBPA  508  out  of  512  bits  of  an 
RSA  key  were  correctly  identified  in  as  few  as  10 
iterations.  (Aciicmez,  Koc  &  Seiffert,  2007) 

In  effect,  SBPA  is  the  process  of  analyzing  a  CPUs 
Branch  Predictor  states  by  spying  on  a  single  computation 
process.  This  one  distinction  provides  a  sharp  contrast 
from  those  attacks  relying  on  statistical  methods  and 
requiring  many  computation  measurements  under  the  same  key. 
The  successful  extraction  of  almost  all  secret  key  bits  by 
an  SBPA  attack  against  an  Open  SSL  RSA  implementation 
demonstrates  that  the  often  recommended  blinding  techniques 
to  protect  RSA  against  side-channel  attacks  are  not,  in  and 
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of  themselves,  enough  to  ensure  adequate  protection  of 
sensitive  information.  (Aciicmez,  Koc  &  Seiffert,  2007) 

5 .  Padding  Schemes 

Practical  RSA  implementations  typically  embed  some 
form  of  structured,  randomized  padding  into  the  value  m 
before  encrypting  it.  This  padding  ensures  that  m  does  not 
fall  into  the  range  of  insecure  plaintexts,  and  that  a 
given  message,  once  padded,  will  encrypt  to  one  of  a  large 
number  of  different  possible  cipher  texts. 

Standards  such  as  PKCS#1  have  been  designed  to 
securely  pad  messages  prior  to  RSA  encryption.  These 
standards  pad  the  plaintext,  m,  with  some  number  of 
additional  bits,  the  size  of  the  padded  message  will  always 
be  larger  than  the  original  message.  RSA  padding  schemes 
must  be  carefully  designed  to  prevent  attacks,  which  could 
capitalize  on  a  predictable  message  structure.  At  a 
minimum  they  should  perform  two  basic  tasks.  The  first  is 
to  add  an  element  of  randomness  that  can  be  used  to  convert 
a  deterministic  encryption  scheme  (e.g.,  always  produces 
the  same  cipher-text  for  a  given  plaintext  and  key,  even 
over  separate  executions  of  the  encryption  algorithm)  into 
a  probabilistic  scheme.  The  second  is  to  prevent  partial 
message  decryption  by  ensuring  that  an  adversary  is  unable 
to  recover  any  portion  of  the  plaintext  without  being  able 
to  backwards  compute  the  one  way  function.  Early  versions 
of  the  PKCS#1  standard  used  a  construction  that  seemed  to 
enhance  RSA  as  a  secure  encryption  scheme.  This  version 
was  later  found  vulnerable  to  an  adaptive  chosen  cipher- 
text  attack.  Later  versions  of  the  standard,  which  include 
Optimal  Asymmetric  Encryption  Padding  (OAEP) ,  prevented 
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such  attacks.  The  PKCS#1  standard  also  incorporates 
processing  schemes  designed  to  provide  additional  security 
for  RSA  signatures,  for  example,  the  Probabilistic 
Signature  Scheme  for  RSA  (RSA-PSS)  . 

D.  CURRENT  STATE  OF  THE  ART 

1 .  How  are  RSA  Encryption  Techniques  Being  Used 
Today? 

Since  the  DoD  first  implemented  smart  card  technology 
based  on  CAC  specifications,  the  Common  Access  Card  has 
served  as  the  standard  ID  card  for  millions  of  active  duty 
military  personnel,  reservists,  DoD  civilian  employees  and 
contractors.  The  CAC  is  becoming  the  principal  card  used 
to  enable  physical  access  to  buildings  and  controlled 
spaces,  and  is  also  being  used  to  support  applications  such 
as  manifesting,  food  service  and  medical  and  dental.  It  is 
also  being  used  to  control  logical  access  to  DoD  computer 
networks  and  systems.  An  individuals  CAC  card  contains 
their  private  key  to  be  used  for  secure  authentication  to 
computer  systems  operating  within  a  given  public  key 
infrastructure . 

According  to  the  DoDs  Access  Card  Office,  the  ultimate 
goal  of  the  CAC  program  is  to  create  an  "any  card,  any 
reader,  any  vendor"  smart  card  environment. 

Using  RSA  type  encryption,  CAC  software  combines  the 
security  of  smart  cards  with  the  strength  of  digital 
certificates  used  for  accessing  networks,  applications  and 
data.  These  cards  have  enabled  the  DoD  to  migrate  from 
passwords  to  digital  certificates  and  finally  to 
comprehensive  PKI  and  single  sign-on  implementations. 
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RSA  SecurlD  Passage  smart  card  software,  the  platform 
on  which  CAC  is  established,  is  a  standards-based  smart 
card  authentication  program  that  ensures  flexibility  and 
information  protection.  It  supports  critical  industry 
standards  including  X.509  v3  certificates,  PKCS  #5,  #11  and 
#12,  CAPI,  SSL  and  qualified  PC/SC  readers.  ("RSA  Security 
Announces,"  2001) 

2 .  RSA  Encryption  and  Key  Management  Suite 

The  RSA  Encryption  and  Key  Management  Suite  is  an 
integrated  suite  of  products  that  protect  information  at 
every  layer  of  the  OSI  model  while  reducing  complexity 
associated  with  point  encryption  key  management  techniques. 
Using  many  of  the  techniques  discussed  earlier  in  this 
chapter,  RSA  can  minimize  the  risk  associated  with  data 
breaches  of  sensitive  information,  intellectual  property, 
and  strategic  and  operational  data.  It  can  meet  encryption 
requirements  for  data  at  rest  and  data  in  transit.  It 
protects  sensitive  information  stored  in  file  systems  on 
servers  and  endpoints,  while  also  securely  storing, 
distributing  and  managing  encryption  keys  throughout  their 
life  cycle.  Finally,  this  suite  allows  secure  application 
design  between  elements  of  the  DoD  and  private  industry 
without  incurring  additional  costs  or  further  extending 
timelines.  ("RSA  Encryption  and  Key  Management,"  2009) 
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III.  NSA  SUITE  B 


A.  INTRODUCTION 

1 .  Background  of  NSA  Suite  B 

The  NSA  Central  Security  Service  states  that,  "the 
sustained  and  rapid  advance  of  information  technology  in 
the  21st  century  dictates  the  adoption  of  a  flexible  and 
adaptable  cryptographic  strategy  for  protecting  national 
security  information."  The  NSA  announced  Suite  B  at  the 
2005  RSA  Conference  as  a  response  to  this  requirement. 
Suite  B  will  complement  the  existing  policy  for  the  use  of 
the  Advanced  Encryption  Standard  (AES)  that  protects 
national  security  systems  and  information.  Suite  B 

includes  cryptographic  algorithms  for  hashing,  digital 
signatures,  and  key  exchange. 

NSA  Suite  B  is  a  subset  of  the  cryptographic 
algorithms  approved  by  the  National  Institute  of  Standards 
and  Technology  (NIST)  and  as  such  is  suitable  for  use 
throughout  DoD  and  all  other  governmental  agencies.  The 
entire  suite  of  cryptographic  algorithms  is  intended  to 
protect  both  classified  and  unclassified  national  security 
systems  and  information.  Beyond  just  the  governmental 
applications,  NSA  Suite  B  will  also  provide  industry  with  a 
common  set  of  cryptographic  algorithms  that  they  can  use  to 
create  products  that  meet  the  procurement  needs  of  the  U.S. 
Government.  (National  Security  Agency  Central  Security 
Service,  2009) 

When  analyzing  Suite  B  it  is  important  to  distinguish 

what  it  is  and  what  it  is  not.  Suite  B  only  specifies  the 

cryptographic  algorithms  to  be  used.  There  are  many  other 
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competing  factors  that  determine  whether  a  particular 
device  that  implements  a  set  of  cryptographic  algorithms 
should  be  used  to  satisfy  a  given  security  requirement. 
The  quality  of  the  implementation  of  the  cryptographic 


algorithm 

in 

software. 

firmware,  or  hardware 

must 

be 

sufficient 

• 

Operational 

requirements  associated 

with 

DoD 

approved 

key 

and  key 

management  activities 

must 

be 

commensurate . 

Another 

point  for  consideration 

is 

the 

sensitivity  or  other  access  restrictions  of  the  information 
to  be  protected  (e.g.,  SECRET,  TOP  SECRET,  NOEORN,  EOUO, 
etc.).  Finally,  the  operational  requirements  for 
interagency  and  international  interoperability  will  always 
be  a  factor.  The  processes  by  which  these  factors  are 
addressed  are  outside  the  scope  of  cryptographic 
technology.  The  primary  focus  of  Suite  B  is  simply 
protecting  the  information.  (National  Security  Agency 
Central  Security  Service,  2009) 

B.  UNDERLYING  CONCEPTS  AND  TECHNOLOGY 

1.  Elliptic  Curve  Cryptography  (ECC) 

Over  the  past  three  decades  Internet  communications 
have  been  secured  by  the  earliest  generations  of  public  key 
cryptographic  algorithms,  most  of  which  were  developed  in 
the  middle  to  late  1970s.  They  have  formed  the  basis  for 
key  management  and  authentication,  Web  traffic  and  secure 
e-mail.  These  public  key  techniques  revolutionized 
cryptography  as  it  had  been  used  and  understood;  however, 
newer  techniques  have  been  developed  that  offer  better 
performance  and  increased  security.  Specifically,  Elliptic 
Curve  (EC)  techniques,  which  were  independently  created  by 
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Neal  Koblitz  and  Victor  Miller,  offer  an  exciting  way  ahead 
for  the  science  of  cryptography. 

In  a  recent  posting  on  the  NSA  website,  they  state 

that,  "the  best  assured  group  of  new  public  key  techniques 
is  built  on  the  arithmetic  of  elliptic  curves.  While 
currently  elliptic  curves  do  not  offer  many  noticeably 
significant  benefits  over  existing  public  key  algorithms, 
over  time  the  evolving  threat  posed  by  eavesdroppers  and 
hackers  with  access  to  greater  computing  resources  will 
demonstrate  what  elliptic  curves  can  offer."  In  general, 
current  PKI  methods  respond  to  new  attacks  by  relying  on, 
and  when  necessary  dramatically  increasing,  their  key 

sizes.  Elliptic  Curve  Cryptography  (ECC)  allows  for  better 
security  with  a  significant  reduction  in  key  size. 

Moreover,  "ECC  has  to  date  exhibited  no  vulnerabilities  to 
increasingly  strong  attack  algorithms,  but  has  remained 
secure  with  little  required  adaptation"  (National  Security 
Agency  Central  Security  Service,  2009) . 

Presently,  the  methods  for  computing  elliptical  curve 
mathmematics  are  much  less  efficient  than  those  for 
factoring  or  computing  integer  factorization  schemes  (such 
as  the  ones  used  in  RSA  encryption)  .  As  a  result,  shorter 
key  sizes  can  be  used  to  achieve  comparable  security  to 

conventional  public-key  cryptosystems.  (Lenstra  &  Verheul, 
2000)  This,  in  turn,  has  the  potential  to  lead  to  less 
memory  requirement  and  improved  performance  vis-a-vis 
smaller  keys  and  faster  computations.  These  advantages  are 
especially  important  in  environments  where  processing 
power,  storage  space,  bandwidth,  or  power  consumption  is 
constrained . 
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a.  ECC  Key  Generation 

A  generic  Elliptic  Curve  (EC)  system  consists  of 
a  public  key  of  a  finite  field  GF(p)  of  size  p,  a  generator 
g  of  the  multiplicative  group  GE(p),  and  an  element  y  of 
GF(p)  that  is  not  equal  to  1 .  In  an  EC  system,  g  generates 
a  subgroup,  q,  of  the  group  of  points  on  an  elliptic  curve, 
E,  over  the  finite  field  GF(p)  .  The  security  is  based  on 
the  difficulty  of  computing  discrete  logarithms  in  the 
subgroup  generated  by  g.  These  subgroup  logarithms  can  be 
computed  only  if  all  the  discrete  logarithms  in  the  full 
group  of  points  on  an  elliptic  curve  over  a  finite  field 
can  be  computed.  This  computational  procedure  is  known  as 
the  Elliptic  Curve  Discrete  Logarithm  (ECDL)  problem. 
There  is  currently  no  better  method  to  solve  the  ECDL 
problem  other  than  to  solve  the  problem  in  all  cyclic 
subgroups  and  then  combine  the  results.  The  difficulty  of 
the  ECDL  problem  depends  on  the  size  of  the  largest  prime 
divisor  of  the  order  of  the  group  of  points  of  the  curve, 
which  is  close  to  p.  For  this  reason,  p,  E,  and  q  are 

usually  chosen  such  that  the  sizes  of  p  and  q  are  close. 

The  security  of  EC  systems,  then,  relies  on  the  size  of  q. 
The  size  of  an  EC  key  refers  to  the  bit-length  of  the 
subgroup  size  q.  The  actual  number  of  bits  required  to 
store  an  EC  public  key  could  conceivably  be  substantially 
larger  than  the  EC  key  size  q,  since  the  public  key 
contains  p,  E,  g,  and  y  as  well.  (Lenstra  &  Verheul,  2000) 

ECC  systems  use  two  kinds  of  curves.  The  first 

kind.  Pseudo-random  curves,  are  those  whose  coefficients 
are  generated  from  the  output  of  a  seeded  cryptographic 
hash.  If  the  seed  value  is  given  along  with  the 
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coefficients,  it  can  be  verified  that  the  coefficients  were 
generated  by  that  method.  The  second  kind.  Special  curves, 
are  those  whose  coefficients  and  underlying  field  have  been 
specifically  selected  to  optimize  the  efficiency  of  the 
elliptic  curve  operations.  (U.S.  Dept  of  Commerce,  2000, 
p.  29) 

b.  Elliptic  Curve  Digital  Signature  Algorithm 

Fundamentally  a  digital  signature  is  simply  the 
digital  version  of  a  handwritten  signature  that  is  used 
every  day  to  demonstrate  that  whatever  was  signed  was  done 
by  one  and  only  one  person.  A  digital  signature  is 
represented  in  a  computer  as  a  string  of  binary  digits  that 
are  dependent  on  the  signers  private  key,  as  well  as  the 
contents  of  the  message.  A  digital  signature  is  computed 
using  a  set  of  rules  and  a  set  of  parameters  such  that  the 
identity  of  the  signatory  and  integrity  of  the  data  can  be 
verified.  An  algorithm  provides  the  capability  to  generate 
and  verify  the  signatures.  Signature  generation  makes  use 
of  a  private  key  to  encrypt  a  hash  of  the  data  being 
signed.  An  adversary,  who  does  not  know  the  private  key  of 
the  signatory,  cannot  generate  the  correct  signature  of  the 
signatory.  More  plainly  stated;  signatures  cannot  be 
forged.  Signature  verification  makes  use  of  a  public  key, 
which  corresponds  to,  but  is  not  the  same  as,  the  private 
key.  By  using  the  signatorys  public  key,  anyone  can  verify 
a  correctly  signed  message.  A  means  of  associating  public 
and  private  key  pairs  to  the  corresponding  users  is 
required.  That  is,  there  must  be  a  binding  of  a  users 
identity  and  the  users  public  key.  This  binding  may  be 
certified  by  a  mutually  trusted  and  unbiased  third  party. 
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Possible  disputes  that  could  arise  will  do  so  either  when  a 
signer  tries  to  deny  a  signature  they  legitimately  created, 
or  when  a  forger  makes  a  fraudulent  claim.  For  both 
signature  generation  and  verification,  the  data,  which  is 
referred  to  as  a  message,  is  reduced  by  means  of  the  Secure 
Hash  Algorithm  (SHA-1)  as  specified  in  the  Federal 
Information  Processing  Standards  (FIPS)  Publication  180-2. 

Digital  signatures  can  be  used  to  provide  basic 
cryptographic  services  such  as  data  integrity,  which 
assures  that  data  has  not  been  altered  by  unauthorized 
means,  data  authentication  that  assures  that  the  source  of 
data  is  as  claimed  and  finally,  non-repudiation,  which 
assures  that  an  entity  cannot  deny  previously  sent 
transmissions.  (U.S.  Department  of  Commerce,  2000) 

The  Elliptic  Curve  Digital  Signature  Algorithm 
(ECDSA)  is  the  elliptic  curve  flavor  of  the  Digital 
Signature  Algorithm  used  in  legacy  cryptosystems.  ECDSA 
was  first  proposed  in  1992  by  Scott  Vanstone  in  response  to 
the  NISTs  request  for  public  comments  on  their  first 
proposal  for  a  Digital  Signature  Standard  (Vanstone,  1992) . 
It  was  accepted  in  1998  as  an  ISO  (International  Standards 
Organization)  standard  (ISO  14888-3),  and  subsequently  in 
1999  as  an  ANSI  (American  National  Standards  Institute) 
standard  (ANSI  X9.62) .  Finally,  in  2000  it  was  accepted  as 
an  IEEE  (Institute  of  Electrical  and  Electronics  Engineers) 
(IEEE  1363-2000)  and  a  EIPS  standard  (EIPS  186-2)  .  (Johnson 
&  Menezes  &  Vanstone,  2001) 

An  ECDSA  key  pair  (public  and  private)  is 
associated  with  a  particular  elliptic  curve.  The  public 
key  is  a  random  multiple  of  the  base  point,  while  the 


private  key  is  the  integer  used  to  generate  the  multiple. 
In  other  words,  given  two  points  G  and  Y  on  an  elliptic 
curve  such  that  Y  =  kG,  k  is  the  private  key  and  Y  is  the 
public  key.  Finding  k  is  another  example  of  the  ECDL 
problem. 

A  large  part  of  the  digital  signature  process 
involves  legitimizing  the  key  pairs  used.  Proving  ownership 
and  validity  greatly  increases  the  quality  of  the  assurance 
of  the  signature.  Public  key  validation  ensures  that  a 
public  key  has  the  requisite  mathematical  properties. 
Successful  execution  of  the  validation  process  demonstrates 
that  an  associated  private  key  logically  exists,  although 
it  does  not  demonstrate  that  someone  actually  has  computed 
the  private  key.  More  importantly,  it  does  not  demonstrate 
that  the  claimed  owner  actually  possesses  the  private  key. 
Practical  reasons  for  performing  public  key  validation 
include  both  prevention  of  malicious  insertion  of  an 
invalid  public  key  and  detection  of  inadvertent  coding  or 
transmission  errors.  (Johnson  &  Menezes  &  Vanstone,  2001) 

In  order  to  prevent  an  entity  from  claiming  a 
fraudulent  public  key,  the  CA  should  require  all  entities 
to  prove  possession  of  the  private  keys  corresponding  to 
its  public  keys  before  the  CA  certifies  the  public  key. 
This  proof  of  possession  can  be  accomplished  in  a  variety 
of  ways.  One  such  method  is  to  require  all  entities  to 
sign  a  message  of  the  CAs  choice.  The  other  is  by  using 
"zero-knowledge"  techniques.  It  is  noteworthy  to  highlight 
the  fact  that  proof  of  possession  of  a  private  key  provides 
different  assurances  from  public  key  validation.  The  former 
demonstrates  possession  of  a  private  key  even  though  it  may 
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correspond  to  an  invalid  public  key,  while  the  latter 
demonstrates  validity  of  a  public  key  but  not  ownership  of 
the  corresponding  private  key.  Doing  both  provides  a 
higher  level  of  assurance  regarding  digital  signatures. 

c.  Elliptic  Curve  Diffie-Hellman  Key  Agreement 

The  elliptic  curve  Diffie-Hellman  scheme  is  a  key 
agreement  scheme  based  on  ECC.  It  is  designed  to  provide 
either  unilateral  or  mutual  key  authentication,  known-key 
security,  and  forward  secrecy.  It  does  this  under  the 
assumption  that  issues  involving  authenticated  public  key 
exchange  and  key  pairs'  states  (ephemeral  vs.  static)  have 
been  resolved  in  accordance  with  NIST  recommendations 
(Certicom  Research,  2000)  . 

Secret  cryptographic  keying  material  may  be 
electronically  established  between  parties  by  using  either 
a  key  agreement  scheme  or  a  key  transport  scheme.  During 
key  agreement  both  parties  contribute  to  the  shared  secret 
and  by  extension  the  derived  secret  keying  material.  The 
secret  keying  material  to  be  established  is  therefore  never 
sent  directly  to  one  person  or  the  other.  Instead, 
information  is  exchanged  between  both  parties  that  then 
allows  each  to  derive  the  secret  keying  material. 

An  alternative  option  to  the  key  agreement  method 
described  above  is  the  use  of  an  asymmetric  key  based  key 
transport  scheme.  During  key  transport  one  party  selects 
the  secret  keying  material .  The  encrypted  or  "wrapped" 
secret  keying  material  is  transported  from  the  sender  to 
the  receiver.  (Barker  &  Johnson  &  Smid,  2007) 


26 


The  elliptic  curve  Dif f ie-Hellman  technique 
examined  here  generates  a  field  element  from  a  secret  key 
owned  by  one  entity  and  a  public  key  owned  by  a  second 
entity  in  such  a  way  that  when  both  execute  the  key 

exchange  technique  with  corresponding  keys  as  input,  they 
will  compute  the  same  field  element.  The  primary  security 
requirement  is  that  an  attacker  who  sees  only  one  entity  or 
the  others  public  key  should  be  unable  to  compute  the 
shared  field  element. 

The  requirement  that  an  attacker  be  unable  to 
derive  the  shared  field  element  is  a  direct  result  of  the 
requirement  that  the  elliptic  curve  Dif f ie-Hellman  problem 
(ECDHP)  be  sufficiently  difficult  to  solve.  The  ECDHP  is 

closely  related  to  the  ECDLP  mentioned  earlier.  If  the 

ECDLP  is  easy  then  the  ECDHP  is  also.  The  converse  is  also 
true  (Boneh  &  Lipton,  1996)  .  Many  key  agreement  schemes 
based  on  Dif f ie-Hellman  actually  rely  on  the  stronger 

requirement  that  the  shared  field  element  is  not  just 
sufficiently  difficult  for  an  attacker  to  predict,  but  that 
the  element  actually  looks  random  to  the  attacker. 
(Certicom  Research,  2000) 

Eor  key  exchange,  NSA  Suite  B  calls  for  the  use 
of  ECDH.  According  to  the  NSA,  ECDH  is  appropriate  for 
incorporation  of  Suite  B  into  many  existing  Internet 
protocols  such  as  the  Internet  Key  Exchange  (IKE), 
Transport  Layer  Security  (TLS) ,  and  Secure  MIME  (S/MIME) . 

d.  Secure  Hash  Algorithms 

There  are  currently  available  four  secure  hash 

algorithms,  SHA  1,  SHA  256,  SHA  384,  and  SHA  512.  All  four 

of  the  algorithms  are  iterative,  one-way  hash  functions 
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that  can  process  a  message  to  produce  a  condensed 
representation  called  a  message  digest.  The  result  is  that 
these  algorithms  can  be  used  to  verify  a  messages 
integrity.  Any  change  to  the  original  message  will  result 
in  a  different  message  digest.  This  capability  is  useful 
in  the  generation  and  verification  of  digital  signatures 
and  message  authentication  codes.  Every  secure  hash 
algorithm  can  be  described  by  its  two  stages  of 
preprocessing  and  hash  computation.  (U.S.  Department  of 
Commerce,  2002) 

Preprocessing  involves  padding  a  message,  parsing 
the  padded  message  into  m-bit  blocks,  and  setting 
initialization  values  for  the  eventual  hash  computation. 
The  hash  computation  generates  a  message  schedule  from  the 
padded  message  and  uses  that  schedule,  along  with 
functions,  constants,  and  word  operations  to  iteratively 
generate  a  series  of  hash  values.  The  final  hash  value 
generated  by  the  hash  computation  is  used  to  determine  the 
message  digest.  The  four  algorithms  differ  most 
significantly  in  the  number  of  "bits  of  security"  that  are 
provided  for  the  data  being  hashed,  which  is  directly 
related  to  the  message  digest  length  and  to  the  deviation 
of  the  algorithms  output  distribution  (i.e.,  how  uniformly 
likely  are  all  possible  output  strings) .  When  a  secure 
hash  algorithm  is  used  in  conjunction  with  another 
algorithm,  there  may  be  additional  requirements  that 
mandate  the  use  of  a  secure  hash  algorithm  with  a  minimum 
number  of  bits  of  security.  For  example,  if  a  message  is 
being  signed  with  a  DSA  that  provides  128  bits  of  security, 
then  that  signature  algorithm  may  require  the  use  of  a 
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secure  hash  algorithm  that  also  provides  128  bits  of 
security  (e.g.,  SHA-256) .  (U.S.  Department  of  Commerce, 

2002) 

Finally,  the  four  algorithms  differ  in  terms  of 
the  size  of  the  blocks  and  words  of  data  that  are  used 
during  hashing.  Table  1  below  lists  the  basic  properties  of 
all  four  secure  hash  algorithms. 


.\lgorithni 

Message  Size 
(bits) 

Block  Size 
(bits) 

M  ol  d  Size 
(bits) 

Message  Digest  Size 
(bits) 

Securits'^ 

(bits) 

sa4-i 

<264 

512 

32 

160 

80 

Sa4-256 

<264 

512 

32 

256 

128 

Sa4-384 

1024 

64 

384 

192 

Sa4-512 

<2^8 

1024 

64 

512 

256 

Table  1.  Secure  Hash  Algorithm  Properties  [From  U.S. 

Department  of  Commerce/National  Institute  of  Standards 

and  Technology  (2002)] 

C.  SECURITY  CONSIDERATIONS 

1.  Message  Encryption  Criteria 

The  majority  of  public  key  systems  in  use  today  use 
1,024-bit  key  parameters.  NIST  has  recommended  that  these 
1,024-bit  key  lengths  be  upgraded  to  something  providing 
more  security  no  later  than  2010.  After  that,  NIST 
recommends  that  they  be  upgraded  once  again  to  something 
providing  even  more  security.  One  course  of  action  would 
be  to  increase  the  key  size  up  to  the  next  level  of  2048 
bits.  Another  viable  option  is  to  move  from  first 
generation  public  key  algorithms  to  elliptic  curve 
algorithms . 
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Key  bit  length  for  a  symmetric  encryption  algorithm  is 
a  common  measure  of  security.  Table  2  gives  some  key  sizes 
recommended  by  NIST  to  protect  keys  used  in  conventional 
encryption  algorithms  like  the  Data  Encryption  Standard 
(DES)  and  the  Advanced  Encryption  Standard  (AES)  together 
with  the  equivalent  key  sizes  for  RSA,  Dif  f  ie-Hellman  and 
elliptic  curves. 


Symmetric  Key  Size  (bits) 

RSA  and  Diffie-Hellman  Key  Size  (bits) 

Elliptic  Curve  Key  Size  (bits) 

80 

1024 

160 

112 

2048 

224 

128 

3072 

256 

192 

7680 

384 

256 

15360 

521 

Table  2.  NIST  Recommended  Key  Size  Equivalents [ From 

National  Security  Agency  Central  Security  Service 

(2009)  ] 


Consistent  with  CNSSP-15,  Elliptic  Curve  Public  Key 
Cryptography  using  the  256-bit  prime  modulus  elliptic  curve 
as  specified  in  FIPS-186-2  and  SHA-256  is  appropriate  for 
protecting  classified  information  up  to  the  SECRET  level. 
Use  of  the  384-bit  prime  modulus  elliptic  curve  and  SHA-384 
are  necessary  for  the  protection  of  TOP  SECRET  information. 

In  order  to  use  RSA  or  Dif f ie-Hellman  to  protect  128- 
bit  AES  keys  one  should  use  3072-bit  parameters,  which  are 
three  times  the  size  of  those  in  use  throughout  the 
internet  today.  The  equivalent  (strength)  key  size  for 
elliptic  curves  is  only  256  bits.  It  rapidly  becomes 
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evident  that  as  symmetric  key  sizes  increase,  the  required 
key  sizes  for  RSA  and  Dif  f  ie-Hellman  increase  at  a  much 
faster  rate  than  the  required  key  sizes  for  elliptic  curve 
cryptosystems  in  order  to  achieve  the  equivalent  security 
strength.  Hence,  elliptic  curve  systems  offer  more 

security  per  bit  increase  in  key  size  than  either  RSA  or 
Dif f ie-Hellman  public  key  systems.  (National  Security 
Agency  Central  Security  Service,  "The  Case  for  Elliptical 
Curves,"  2009) 

2 .  ECC  Vulnerabilities 

In  general,  the  best  attacks  on  the  elliptic  curve 
discrete  logarithm  problems  have  been  brute-force.  The 
absence  of  algorithm  specific  attacks  seems  to  indicate 
that  shorter  key  sizes  for  elliptic  cryptosystems  appear  to 
give  similar  security  as  much  larger  keys  that  might  be 
used  in  cryptosystems  based  on  the  discrete  logarithm 
problem  or  integer  factorization.  That  stated,  there  are 
more  efficient  attacks  that  exist  for  certain  choices  of 
elliptic  curves.  According  to  Menezes,  Okamoto,  and 
Vanstone  the  elliptic  curve  discrete  logarithm  problem  has 
been  reduced  to  the  more  easily  solvable  traditional 
discrete  logarithm  problem  for  certain  specific  curves 
(Menezes,  Okamoto,  and  Vanstone,  1990) .  The  implication  of 
this  is  that  the  same  size  keys  as  are  used  in  more 
traditional  public  key  systems  are  now  required  for  those 
specific  elliptical  curves.  However,  these  instances  of 
vulnerability  are  readily  classified  and  easily  avoided  and 
therefore  do  not  pose  much  of  a  problem. 

In  1997,  elliptic  curve  cryptography  began  to  receive 
more  attention  from  researchers  looking  to  test  its 
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security.  By  the  end  of  the  nineties,  there  were  no  major 
improvements  found  to  be  necessary  in  the  reliability  of  EC 
cryptosystems.  According  to  RSA  Laboratories,  the  longer 
this  situation  continues,  the  more  public  confidence  will 
grow  that  ECC  really  does  offer  as  much  strength  as 
advertised.  However,  there  is  some  evidence  that  the  use 
of  special  elliptic  curves,  which  provide  very  fast 
implementations,  might  allow  new  specialized  attacks.  As  a 
starting  point,  the  basic  brute-force  attacks  can  be 
improved  when  attacking  these  curves.  Continued  research 
into  elliptic  curve  cryptosystems  might  eventually  create 
the  same  level  of  widespread  trust  as  in  other  public-key 
techniques  however,  "the  use  of  special  purpose  curves  will 
most  likely  always  be  viewed  with  extreme  skepticism."  (RSA 
Security,  1998) 

3.  ECDSA  Vulnerabilities 

The  security  objective  of  ECDSA  is  to  be 
"existentially  unforgeable"  against  a  chosen  message 
attack.  The  goal  of  an  adversary  who  launches  such  an 
attack  against  a  legitimate  entity  is  to  obtain  a  valid 
signature  on  a  single  message,  after  having  obtained  the 
legitimate  entitys  signature  on  a  collection  of  other 
messages  of  the  adversarys  choice. 

According  to  Certicoms  publication  on  ECDSA,  "Some 
progress  has  been  made  in  trying  to  prove  the  security  of 
ECDSA,  albeit  in  theoretical  models.  Slight  variants  of 
DSA  and  ECDSA  (but  not  ECDSA  itself)  have  been  proven  to  be 
existentially  unforgeable  against  chosen  message 
attack.. .under  the  assumptions  that  the  discrete  logarithm 
problem  is  hard  and  that  the  hash  function  employed  is  a 

32 


random  function.  ECDSA  itself  has  been  proven  secure  by 
Brown  under  the  assumption  that  the  underlying  group  is  a 
generic  group  and  that  the  hash  function  employed  is 
collision  resistant." 

All  possible  attacks  on  ECDSA  can  be  categorized  into 
one  of  three  possible  classifications.  The  first  is 
attacks  on  the  elliptic  curve  discrete  logarithm  problem. 
The  second  is  attacks  on  the  hash  function  employed.  The 
third  falls  into  the  ubiquitous  "other  attacks"  category. 
(Johnson  &  Menezes  &  Vanstone,  2001,  p.28) 

4 .  ECDH  Vulnerabilities 

A  direct  assault  on  the  ECDH  problem  is  not  the  only 
way  an  attacker  might  attempt  to  break  the  Dif f ie-Hellman 
key  agreement  scheme.  ECDH  key  agreement  schemes  could 
also  be  susceptible  to  small  subgroup  attacks  (Johnson, 
1996)  (Lim  &  Lee,  1997)  in  which  an  adversary  substitutes  a 
users  public  key  with  a  point  of  small  order  in  an  attempt 
to  coerce  a  different  entity  (or  user)  to  calculate  a 
predictable  field  element  using  one  of  the  DH  primitives. 
A  successful  attack  of  this  type  could  result  in  the 
compromise  of  a  session  key  shared  by  two  entities,  or  in  a 
worst-case  scenario,  even  the  compromise  of  one  of  the 
entitys  secret  keys. 

Two  defenses  recommended  against  this  attack  are 

either  to  validate  a  users  public  key  and  use  the  standard 

Dif f ie-Hellman  primitive,  or  partially  validate  the  entitys 

public  key  and  use  the  cofactor  Dif f ie-Hellman  primitive. 

Which  defense  is  appropriate  in  a  given  situation  will 

depend  on  issues  like  whether  or  not  interoperability  with 

existing  use  of  the  standard'  Dif f ie-Hellman  primitive  is 

33 


desirable  (the  first  defense  interoperates  while  the  second 
does  not)  ,  and  what  the  efficiency  requirements  of  the 
system  are  (the  second  defense  is  usually  more  efficient) . 
(Certicom  Research,  2000) 

D.  CURRENT  STATE  OF  THE  ART 

To  date  ECC  adoption  in  the  industry  has  been  slow, 
but  is  gaining  momentum  thanks  to  the  recent  NSA 
endorsement  of  its  advantages  over  RSA.  There  have  been  a 
number  of  important  industries  and  government  organizations 
who  are  adopting  ECC,  but  most  notably  eGovernment  IDM 
(Identity  Management)  initiatives  in  Austria.  Austria 
began  a  phased  implementation  of  Health  insurance  e-cards 
in  May  2005  and  was  completely  running  by  November  of  the 
same  year.  Health  insurance  e-cards  use  elliptic  curve 
cryptography,  NIST  recommended  192  bit  prime  field  curve. 
(Austrian  Profile,  2007) 

Adoption  of  ECC  by  smart  card  vendors  has  been  also 
steadily  increasing.  In  January  2007,  one  of  the  smart 
card  chipmakers,  Infineon,  announced  that  Certicom  Incs 
Suite  B  Power  Bundle  will  be  included  in  the  Infineon  smart 
card  microcontrollers,  which  will  comply  with  USGs  Suite  B 
specifications  by  providing  Infineon  ECC-enabled  smart  card 
microcontrollers  and  Certicom  software  tools  for  the  USGs 
Personal  Identity  Verification  (PIV)  cards  and  other 
applications.  (Certicom,  2007)  Additionally,  Oberthur  Card 
Systems  just  recently  received  FIPS  140-2  Level  3 
certification  on  their  128K  smart  card  with  ECC. 

Another  major  industry  that  is  adopting  ECC  is  the 

utility  industry,  where  they  are  trying  to  modernize  their 

meter  reading  and  data  collection  system  with  advanced 
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metering  infrastructure.  In  May  of  2008  Certicom  launched 
a  new  Device  Authentication  Service  for  ZigBee  Smart 
Energy.  The  service  uses  ECC  to  secure  wireless  data 
communication  and  authenticate  smart  metering  devices. 
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IV.  COMPARE  AND  CONTRAST 


A.  INTRODUCTION 

In  this  chapter,  we  will  compare  and  contrast  the 
performance,  advantages,  disadvantages,  and  usability  of 
ECC  and  RSA  based  cryptosystems. 

B.  DATA  COLLECTION  AND  RESEARCH 

The  data  collection  methodology  used  in  this  thesis 
includes  both  results  from  our  own  testing  as  well  as  from 
findings  from  independent  research  companies  like  Certicom 
Inc.  and  RSA. 

1 .  Empirical  Data 

As  the  DoD  prepares  to  move  forward  with  CAC  platform 
cryptographic  migration  from  RSA  1024  to  RSA  2048,  the  CAC 
Test  Lab  (CTL)  headed  by  one  of  the  authors  of  this  thesis, 
J.  Shu,  and  located  within  the  Defense  Manpower  Data  Center 
(DMDC)  has  performed  exhaustive  benchmark  testing  in  order 
to  determine  the  average  time  required  to  produce  CAC  cards 
personalized  with  End  Entity  (EE)  RSA  2048  Certificates. 
CAC  issuance  infrastructure  testing  of  RSA  2048  keys  and 
SHA-1  signatures  are  part  of  the  requirement  for  the 
cryptographic  migration  test  plan.  The  CTL  issued  a  paper 
on  the  results  of  issuance  testing  with  enlarged  key  sizes 
from  EE  RSA  1024  to  EE  RSA  2048  bit  key  length  and  SHA-1 
signature  done  from  a  Real-time  Automated  Personnel 
Identification  System  (RAPIDS)  workstation.  These  results 
are  the  basis  for  our  comparative  analysis  of  the  two  RSA 
key  lengths . 
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2 .  Methods 


RAPIDS  is  the  DoDs  main  form  of  CAC  issuance.  As 
such,  the  DMDC  CTL  conducted  an  in-depth  analysis  of  the 
RAPIDS  logs,  which  were  found  to  contain  a  wealth  of 
information  regarding  key  generation  times.  The  CTL 

approach  was  to  look  at  the  Application  Protocol  Data  Unit 
(APDU)  commands  embedded  into  the  RAPIDS  logs  and  in 
conjunction  with  the  time  stamps  associated  with  the 
commands,  measure  the  individual  specific  time  lapses.  In 
this  way,  they  were  able  come  up  with  a  quantifiable  value 
associated  with  the  establishment  of  each  key  generation. 
To  compensate  for  the  considerable  size  of  each  log  the  CTL 
engineers  developed  data  pattern  recognition  applications, 
which  were  used  to  examine  and  sift  through  the  RAPIDS 
logs . 

Pattern  recognition  applications  work  by 

systematically  processing  every  line  from  a  RAPIDS  log. 
The  CTL  application  used  a  recursive  process  to  either 
filter  out  unimportant  lines  or  to  extrapolate  significant 
data  points  from  relevant  lines.  In  this  fashion  the  CTL 
was  able  to  process  an  entire  directory  worth  of  files,  so 
that  multiple  RAPIDS  log  files  could  simultaneously  be 
examined.  Once  the  information  from  the  log  files  had  been 
culled,  the  exact  amount  of  time  needed  to  complete  each 
key  generation  was  collected.  It  is  important  to  note  that 
the  CTL  focused  on  APDU  information  exchange  between  the 
CAC  and  the  RAPIDS  station  with  particular  regard  to  the 
time  required  to  complete  the  communication.  The  CTL  did 
not  include  an  investigation  of  the  impact  on  networking; 
nor  will  this  thesis. 
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3.  Testing 

Each  testing  station  was  configured  to  record  issuance 
times  for  each  card  issued.  In  order  to  most  effectively 
compare  issuance  and  key  generation  time,  a  critical 
comparison  of  smartcard  RSA  'on  card'  key  generation  using 
2048-bit  and  1024-bit  keys  was  conducted. 

C.  RSA  1024  VS.  RSA  2048 

Presently  the  DoD  CAC  performs  three  RSA  key 
generations  inside  of  the  smart  card  for  total  security 
assurance.  After  the  CTL  collected  the  RSA  key  generation 
data  it  was  then  able  to  calculate  a  statistical  analysis 
on  the  timing  difference  between  RSA  1024-bit  and  2048-bit 
keys  . 

1 .  On-Card  Key  Generation  Analysis 

As  previously  stated,  the  algorithm  for  RSA  key 
generation  involves  finding  two  large  prime  numbers  from 
which  key  pairs  are  able  to  be  generated.  Finding  the  two 
large  prime  numbers  is  the  most  time  consuming  step  in  the 
RSA  key  generation  process.  Using  a  random  number  as  a 
starting  point  to  find  the  two  large  prime  numbers  they  are 
then  multiplied  together  to  form  the  composite  number. 
This  composite  is  the  key  strength  (e.g.,  2048  bits  or  1024 
bits)  .  The  security  of  RSA  is  based  on  the  difficulty  of 
calculating  the  prime  factors  of  large  composite  numbers. 

The  time  difference  between  1024  and  2048  bit  "on 
card"  RSA  key  generation  can  be  substantial  due  to  the 
simple  fact  that  larger  numbers  are  much  more  difficult  to 
factor  than  smaller  ones.  The  difference  in  finding 

factors  of  a  composite  number  of  2048  bits  as  compared  to  a 
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composite  number  that  is  a  factor  of  1024  bits  is  non¬ 
trivial.  In  fact,  although  the  2048-bit  key  is  twice  the 
size  of  1024-bit  key,  the  2048-bit  key  generation  times 
takes  about  nine  to  ten  times  longer  to  complete.  Figure  1 
shows  the  average  key  generation  time  for  both  the  RSA  2048 
and  RSA  1024-bit  lengths.  The  average  time  for  the  2048 
bits  is  approximately  48  seconds  and  the  average  time  for 
the  1024  bits  is  approximately  5  seconds  for  each  key 
generation . 


1024  vs  2048  Average  Key  Generation 
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Figure  1 .  Average  Key  Generation  Time 


2.  RSA  2048  Key  Generation 

Figure  2  shows  the  results  of  the  total  time  it  took 
to  complete  key  generations  for  the  2048-bit  keys.  The 
majority  of  the  key  generations  took  approximately  30  to  80 
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seconds  to  be  generated.  The  average  key  generation 
occurred  around  approximately  45  seconds. 


Figure  2.  2048-Bit  Key  Generation  Times 

Figure  3  also  shows  the  results  for  the  time  it  took 
to  generate  a  key  for  the  2048  bit,  however  this  second 
plot  also  includes  a  confidence  interval  showing  where  a 
key  generation  is  most  likely  to  be  completed. 
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Confidence  Interval  for  2048  Key  Generation 


Time  (s) 

Figure  3.  2048-Bit  Key  Generation  Times  w/  Cl 

Figure  4  shows  the  probability  distribution  of  the 
time  it  took  to  generate  a  key  for  the  2048  bits.  It  is 
most  likely  that  key  generations  were  completed  in  the 
range  of  approximately  30  to  75  seconds.  A  key  is  most 
likely  to  be  generated  at  approximately  48  seconds.  CTL 
uses  the  normal  distribution  or  Gaussian  distribution  to 
describe  data  that  clusters  around  a  mean  or  average.  The 
probability  density  function  for  a  normal  distribution  is 
given  by  the  formula 
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where  la  is  the  mean,  a  is  the  standard  deviation  (a  measure 
of  the  "width"  of  the  bell)  ,  and  exp  denotes  the 
exponential  function. 


Figure  4.  2048-Bit  Key  Generation  Probability  Distribution 

3.  RSA  1024  Key  Generation 

Figure  5  shows  the  results  of  the  total  time  it  took 
to  complete  key  generations  for  the  1024-bit  keys.  The 
majority  of  the  key  generations  took  approximately  2  to  7 
seconds  to  be  generated.  The  average  key  generation 
occurred  at  approximately  5.5  seconds. 
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1024  Key  Generation 


Figure  5.  1024-Bit  Key  Generation  Times 

Figure  6  also  shows  the  results  for  the  time  it  took 
to  generate  a  key  for  the  1024-bit  keys,  however  the  plot 
also  includes  a  confidence  interval  showing  where  a  key 
generation  is  most  likely  to  be  completed. 
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Confidence  Interval  for  1024  Key  Generation 
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Figure  6.  1024-Bit  Key  Generation  Times  w/  Cl 

4.  Encryption/Decryption/Signing  Comparison 

In  an  attempt  to  compare  the  two  RSA  key  length 
metrics  even  further,  results  from  recent  DISA  testing 
demonstrating  everyday  usages  were  studied.  The  following 
figures  were  published  at  the  2009  DoD  Identity  Protection 
Management  (IPM)  Conference  in  Miami,  Florida. 

Figure  7  plots  a  side-by-side  comparison  of  RSA  1024 
and  RSA  2048  digital  signatures.  There  are  no  obvious 
significant  differences  in  the  timing  however,  it  is 
noteworthy  that  the  time  required  to  complete  any  given 
signature  is  non-trivial ;  in  some  cases  taking  longer  than 
twelve  seconds  to  sign  an  email  with  a  1  MB  attachment. 
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Figure  7.  Digital  Signature  Comparison 

Figure  8  compares  the  encryption  speeds  for 
scenarios  involving  email  and  corresponding  appl 
that  are  commonly  used  when  transmitting  data, 
encryption  times  are  relatively  comparable  and  so 
distinguish  one  key  size  over  the  other. 
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Figure  8.  RSA  1024  vs.  RSA  2048  Email  Encryption  Timing 


Figure  9  below  illustrates  a  similar  comparison,  in 
this  instance  focusing  on  the  decryption  times.  The  reader 
will  note  that  the  decryption  times  are  even  more  difficult 
to  distinguish  since  they  are  similar  in  almost  every 
scenario  save  the  MS  Office  2003  SP2  with  email  attachment. 
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Figure  9.  RSA  1024  vs.  RSA  2048  Email  Decryption  Timing 


The  most  likely  reason  for  the  similarities  in 
encryption/decryption  timing  for  the  two  key  lengths  is  the 
fact  that  most  of  the  cryptographic  operations  are  done  on 
the  computer  (not  on  the  smart  card)  ,  which  means  that 
faster  resources  are  more  freely  available. 


D.  ECC  AND  RSA  CRITICAL  COMPARISON 

1.  ECC  Data 

At  the  time  of  the  writing  of  this  thesis,  the  authors 
did  not  have  access  to  a  smart  card  platform  with  ECC 
implementation.  As  such,  collection  of  performance  data 
similar  to  on-card  key  generation  was  not  possible.  The 
focus  of  our  research  was  on  experiments  that  others  have 
done  in  comparing  RSA  and  ECC,  from  which  we  have  drawn 
conclusions . 
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a.  Certicom  Study 

In  May  of  1998  Certicom  Inc.,  the  company  that 
owns  most  ECC  related  patents,  published  a  paper  on  ECC 
implementations  in  smart  cards.  Certicom  Inc.  has  run 
benchmarks  on  a  number  of  different  platforms.  Table  3 
below  is  a  sample  benchmark  in  Solaris  (167  MHz  Ultra  SPARC 
running  Solaris  2.5.1)  platforms  to  test  the  performance  of 
Certicoms  163-bit  ECC  implementation  relative  to  1024-bit 
RSA  implementations.  The  1024-bit  RSA  key  pair  generation 
(4.7  seconds)  is  significantly  slower  than  163  bit  ECC 
(.0038  seconds).  Signing  speeds  are  also  consistently  many 
times  faster  than  those  of  RSA  due  to  the  fact  that  the 
mathematical  operations  used  for  signatures  and 
encryption/decryption,  are  completely  different. 
(Certicom,  2000) 


Function 

Security  Builder  1.2 
163-bit  ECC  (ins) 

ESAFE  3.0 

1.024-bit  RSA  (ms) 

Key  Pail'  Generation 

3.8 

4.708.3 

Sign 

2.1  (ECNRA) 

3.0  (ECDSA) 

228.4 

Verify 

9.9  (ECNRA) 

10.7  (ECDSA) 

12.7 

Diffie-Hellinan  Key  Exchange 

7.3 

1.654.0 

Table  3.  Solaris  Sample  Benchmark  [From  Certicom,  2000] 

b.  Research  In  Motion  (RIM)  Study 

The  maker  of  BlackBerry,  Research  In  Motion 
(RIM)  ,  conducted  a  comparative  analysis  of  RSA  and  ECC  for 
128-bit  security  strength  in  2004.  The  similarity  between 
the  DoD  CAC  and  a  typical  BlackBerry  device  is  the  use  of  a 
public  key  mechanism  to  manage  the  number  of  required  keys. 
RIM  chose  the  Simple  Password  Exponential  Key  Exchange 
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(SPEKE)  ,  which  is  the  same  as  the  previously  discussed 
Dif f ie-Hellman  key  agreement  protocol,  except  that  the  hash 
of  the  password  is  used  as  the  generator  of  the  group. 

NIST  recommends  256  bits  of  security  for 
classified  government  communications.  The  RIM  team  tested 
512-bit  Elliptic  Curve  Dif f ie-Hellman  (ECDH) ,  equivalent  to 
15360-bit  RSA  or  15360-bit  Dif f ie-Hellman  according  to  NIST 
Publication  800-57.  Each  of  these  algorithms  have  their 
own  advantages  and  trade-offs.  Large  keys  have  an  impact 
on  the  performance  of  power  and  bandwidth  constrained 
devices.  RIM  ran  a  series  of  tests  to  determine  the 
performance  levels  of  the  above  three  algorithms  for  key 
generation,  encryption/verification  (with  a  public  key)  and 
decryption/  signature  (with  a  private  key) . 

Generally,  ECC  had  the  fastest  times  for  a 
general  purpose  cryptosystem.  RSA,  however,  is  good  for 
situations  where  only  public  key  verification  is  needed. 
In  the  end,  RIM  decided  to  implement  a  hybrid  solution  for 
their  BlackBerry  device.  ECC  is  their  preferred  choice  of 
cryptosystem  for  systems  requiring  a  high  level  of 
security,  key  generation,  or  private  key  operations, 
however,  for  operations  involving  only  public  keys  (e.g., 
verifying  a  signature) ,  RSA  is  RIMs  preferred  choice  since 
an  RSA  public  key  operation  is  so  much  faster.  RSA 
encryption  is  used  on  the  BlackBerry  for  signature 
verification.  The  timing  results  listed  in  Table  4  below 
were  taken  using  a  BlackBerry  7230  with  128-bit  security. 
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ECC  (256)  RSA  (3072) 

DH  (3072) 

Key  generation 

166  ms 

Too  long 

38  s 

Encrypt  or  verify 

150  ms 

52  ms 

74  s 

Decrypt  or  sign 

168  ms 

8s 

74  s 

Table  4.  ECC  256  vs  RSA  3072  Performance  Comparison 

[From  Certicom,  2004] 

c.  Palm  Device  Study 

Neil  Daswani  from  Stanford  University  studied 
performance  of  various  ECC  and  RSA  cryptographic  primitives 
on  various  Palm  OS  platforms.  Figure  10  shows  interesting 
performance  data  on  the  Palm  OS.  In  studying  the  Wireless 
Transport  Layer  Security  (WTLS)  protocol,  the  cryptographic 
requirements  of  the  protocol,  and  the  time  required  to 
execute  the  required  operations,  Daswani  found  that  1024- 
bit  RSA  based  handshakes  can  be  up  to  twice  as  fast  as  163- 
bit  ECC  based  handshakes  for  server-authenticated  WTLS 
connections,  and  that  163-bit  ECC  based  handshakes  are  at 
least  8  times  as  fast  as  1024-bit  RSA-based  handshakes  for 
mutually-authenticated  WTLS  connections.  (Daswani,  n.d.) 
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New  Palm  MI 
(Dragonball-EZ. 
20MHz.  PalmOS 
v,3.2.5)  (ms) 

Palm  V 

(Dragonball-EZ. 
16.6^^Hz.  PalmOS 
v,3.3)  (ms) 

Old  Palm  MI 
(Dragonball. 
16.6\IHz.  PalmOS 

V.  3.1)  (ms) 

ECC  Benclunarks  (163-bit) 

Key  Generation 

372,4 

514 

556 

Key  Expansion* 

254.8 

350 

378 

Diffie-Hellnian  Key  Agreement 

335.6 

462 

500 

ECC-DSA  Signatme 

514.8 

713 

773 

Generation 

ECC-DSA  Signatme 

1254 

1740 

1885 

Verification 

RSA  Benclmiarks(  1024-bit)^ 

Private  Enciypt 

21734 

27808 

29628 

Public  Deciypt  (e=3) 

598 

758 

790 

Public  Deciypt  (e=65  53  7) 

1482 

1860 

1966 

Public  Enciypt 

622 

798 

834 

Figure  10.  Execution  times  for  RSA  and  ECC  cryptographic 

primitives  [From  Daswani,  n.d.) 


d. 

Trusted  Platform  Module  (TPM) 

Study 

In 

2007 

Beijing  University 

of 

Technology 

conducted  a 

study 

on  ECC  implementation 

of 

the  Trusted 

Platform  Module.  The  TPM  is  a  microcontroller  that  stores 


keys,  passwords  and  digital  certificates.  It  typically  is 
affixed  to  the  motherboard  of  a  PC,  but  could  potentially 
be  used  in  any  computing  device  that  requires  these 
functions.  The  nature  of  the  TPM  is  similar  to  smart  cards 
in  that  they  are  both  hardware  based  protection  solutions 
and  they  both  aim  to  be  bandwidth  and  power  efficient 
devices.  The  TPM  ensures  that  the  information  stored  on  it 
is  made  (more)  secure  from  external  software  attack  and 
physical  theft.  Smart  cards  are  analogous  to  lightweight 
versions  of  the  TPM  (without  the  physical  theft  prevention 
aspects) . 

The  researchers  looked  into  the  silicon  gate 
count  of  TPM.  A  silicon  gate  performs  some  logical 

operation  (e.g.,  and,  or,  xor)  ,  and  they  are  primarily 
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implemented  electronically  using  transistors.  Researchers 
found  that  implementing  ECC  does  offer  improvements  in 
software  performance,  but  ECC  can  be  particularly  efficient 
in  reducing  hardware  workload  due  to  increased  efficiency. 
As  computing  environments  move  to  trusted  environments  and 
hardware-based  implementations  of  security  functions,  the 
benefits  of  ECC  will  increase  dramatically  in  comparison  to 
RSA.  Optimized  chip  designs  have  been  shown  to  be  as  much 
as  37  times  faster  than  comparable  implementations  in 
software.  As  technology  improves,  the  size  of  chip  tends 
to  shrink  by  a  factor  of  ten  (e.g.,  3,260  gates  compared  to 
34,000  gates  as  seen  in  Table  5) .  When  optimized  for  speed, 
ECC  is  seven  times  faster  when  implementing  current  key 
lengths  (1024-bit  RSA  at  2.6  ms  vs.  ECC-163  at  0.35  ms), 
and  more  than  80  times  faster  when  using  key  lengths  on  the 
horizon  for  future  security  levels.  (Zhang  &  Zhou  &  Zhuang 
&  Li,  2007) 


Algorithm 

Optimization 

Time 

Gate  count 

RSA- 1024 

ECC-163 

Space-  optimized 

4.90ms 

0.66ms 

34,000 

3,260 

RSA- 1024 

ECC-163 

Speed-  optimized 

2.60ms 

0.35ms 

150,000 

48,400 

RSA-3072 

ECC-283 

Space-  optimized 

184ms 

29ms 

50,000 

6,660 

RSA-3072 

ECC-283 

Speed-  optimized 

110ms 

1.3ms 

189,200 

80,100 

Table  5.  ECC  and  RSA  gate  counts  [Erom  Zhang  &  Zhou  & 

Zhuang  &  Li  2007] 

The  Beijing  Institute  of  Technology  researchers 
concluded  that  elliptic  curve  cryptography  is  better  suited 
to  be  used  in  TPM  than  the  currently  popular  2048-bit  RSA 
because  it  is  able  to  provide  better  performance  during 
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signature  and  verification  operations  while  appending  less 
overhead  to  the  certificate.  Additionally  it  provides  gate 
counts  for  ECC  that  are  significantly  smaller,  which  means 
lower  chip  costs.  ECC  requires  fewer  processor  cycles, 
which  allows  the  device  to  create  less  heat  and  ultimately 
less  power  drain.  finally,  it  requires  less  bandwidth  for 
transactions  due  to  more  efficient  protocols. 

e.  Sun  Microsystems  SSL  Performance  Study 

Researchers  at  Sun  Microsystems  and  Dogulus 
Stebila  performed  a  number  of  experiments  on  replacing  RSA 
with  ECC  in  secure  Web  transactions.  Table  6  shows  that 
there  is  significant  benefit  to  be  gained  from  using  ECC  in 
SSL/TLS.  ECC  outperformed  RSA  by  a  factor  of  2.4  measuring 
operations  per  second  (1024-bit  RSA  and  160-bit  ECC) . 
Likewise,  operations  per  second  were  improved  by  a  factor 
of  11  using  2048-bit  RSA  and  224-bit  ECC.  Researchers  used 
Apache  2.0.45  compiled  with  OpenSSL  on  a  900  MHz  UltraSPARC 
111.  (Gupta  &  Stebila  &  Shantz,  2004) 


ECC- 160 

RSA- 1024 

ECC-224 

RSA-2048 

Ops  sec 

271.3 

114.3 

195.5 

17.8 

Speed  up 

2  - 

h  1 

11 

:  1 

Table  6.  Secure  Web  transaction  efficiency  [Erom  Gupta  & 

Stebila  &  Shantz,  2004] 

E.  THREATS  AND  VULNERABILITIES 
1 .  ECC  Challenges 

In  1997,  Certicom  Inc.  issued  the  ECC  challenge  in 
order  to  demonstrate  the  security  of  ECC.  By  announcing  a 
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list  of  elliptic  curves  and  associated  ECDLP  parameters 
they  set  the  stage,  additionally  offering  a  reward  for 
solving  the  problem. 

For  ECC  over  prime  fields  GF(p),  challenges  have  been 
defined  for  the  bit  sizes,  k  =  {79,  89,  97,  109,  131,  163, 

191,  239}.  Certicom  provided  estimates  for  the  required 

number  of  machine  days  for  solving  each  challenge  based  on 
Intel  Pentium  100  processors.  The  160  bit  and  above,  still 
requires  a  prodigious  amount  of  computational  power  and  is 
too  costly  to  attack.  Based  on  previous  successful 
attempts  to  solve  the  ECDLP  with  smaller  values  for  k,  a 
successful  attack  against  ECC-163  with  a  one  year  time 
limit  would  require  I.IOXIO^'IO  processors,  which  would  cost 
on  the  order  of  $5.8X10''ll.  These  staggering  numbers  are 
2900  times  larger  than  the  cost  of  a  special  purpose 
hardware  attack  on  1024-bit  length  RSA.  The  ultimate 
conclusion  is  that  ECC  is  as  secure  as  had  been  commonly 
advertised.  (Cueneysu  &  Paar  &  Pelzl,  2007) 

F.  KEY  MEASURES  OF  EFFECTIVENESS/PERFORMANCE  (MOE/MOP) 

1.  Key  Efficiency 

Elliptic  curve  cryptosystems  are  demonstrably  more 

computationally  efficient  than  the  first  generation  public 

key  systems  currently  in  use.  Although  elliptic  curve 

arithmetic  is  slightly  more  complex  per  bit  than  either  RSA 

or  DH  arithmetic,  the  added  "strength  per  bit"  would  seem 

to  compensate  for  any  extra  compute  time.  The  following 

table  shows  the  ratio  of  DH  computation  versus  EC 

computation  for  each  of  the  key  sizes  listed  in  Table  2  of 

Chapter  III.  (National  Security  Agency  Central  Security 

Service,  "The  Case  for  Elliptical  Curves",  2009) 
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Security  Level 
(bits) 

Ratio  of 

DH  Cost  ;  EC  Cost 

80 

3:1 

112 

6:1 

128 

10:1 

192 

32:1 

256 

64:1 

Table  7.  Relative  Computation  Costs  of  Dif f ie-Hellman  and 

Elliptic  Curves  [From  National  Security  Agency  Central 

Security  Service,  2009] 

Until  recently,  the  complexity  of  generating  keys  on  a 
smart  card  was  inefficient  and  often  impractical.  With 
ECC,  the  time  needed  to  generate  a  key  pair  is  so  short 
that  even  a  device  with  the  very  limited  computing  power  of 
a  smart  card  can  generate  a  secure  key  pair,  provided  a 
good  random  number  generator  is  available.  This  also  means 
that  the  card  personalization  process  can  be  streamlined 
for  applications  in  which  non-repudiation  is  important. 

2 .  Key  Strength 

Cryptographic  algorithms  that  provide  security 
services  are  specified  in  the  NIST  800-57  publication. 
Several  of  these  algorithms  are  defined  for  a  number  of  key 
sizes.  NIST  provides  guidance  for  the  selection  of 
appropriate  algorithms  with  the  corresponding  key  sizes. 
It  emphasizes  the  importance  of  acquiring  cryptographic 
systems  with  appropriate  algorithm  and  key  sizes  to  provide 
adequate  protection  for  the  expected  lifetime  of  the  system 
as  well  as  any  data  protected  by  that  system  during  the 
expected  lifetime  of  the  data. 
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a.  Comparable  Algorithm  Strengths 

Different  cryptographic  algorithms  provide 
different  levels  of  strength,  depending  on  the  algorithm 
and  the  key  size  used.  Two  algorithms  are  considered  to  be 
comparable  for  their  given  key  sizes  if  the  amount  of  work 
needed  to  determine  the  keys  is  approximately  the  same 
using  a  given  resource.  The  security  of  an  algorithm  for  a 


given  key 

size  is 

traditionally 

described 

in  terms  of  the 

amount  of 

work  it 

takes  to 

try 

all  keys 

for  a 

s  ymme  trie 

algorithm 

with  a 

key  size 

of 

X  that  has  no 

short-cut 

attacks . 

An  algorithm  that 

has  a  Y-bit 

key. 

but  whose 

strength  is  comparable  to  an  X-bit  key  of  a  different 
symmetric  algorithm  is  said  to  provide  X  bits  of  security. 
An  algorithm  that  provides  X  bits  of  security  would,  on 
average,  take  t2 of  time  to  attack,  where  T  is  the 
amount  of  time  that  is  required  to  perform  one  encryption 
of  a  plaintext  value  and  comparison  of  the  result  against 
the  corresponding  cipher-text  value. 

Table  8  below  provides  comparable  security 
strengths  for  the  Approved  algorithms. 
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Bits  of 

security 

Symmetric 

key 

algorithms 

FFC 

(e.g.,  DSA,  D-H) 

IFC 

(e.g., 

RSA) 

ECC 

(e.g^ 

ECDSA) 

80 

2TDEA''' 

i  =  1024 

.V=  160 

k=  1024 

/=  160-223 

112 

3TDEA 

L  =  2048 

-V=224 

II 

o 

00 

/=  224-255 

128 

AES-128 

I  =  3072 

.V=256 

A' =  3072 

/=  256-383 

192 

AES-192 

L  =  7680 

.V=384 

k  =  7680 

/=  384-511 

256 

AES-256 

L  =  15360 

N=  512 

k=  15360 

/=512- 

Table  8.  Common  Algorithm  Strength  Comparison  [From  NIST, 

2007] 

Column  1  indicates  the  number  of  bits  of  security 
provided  by  the  algorithms  and  key  sizes  in  a  particular 
row.  Column  2  identifies  the  symmetric  key  algorithms  that 
provide  the  indicated  level  of  security.  Column  3 

indicates  the  minimum  size  of  the  parameters  associated 
with  the  standards  that  use  finite  field  cryptography 
(FFC) .  Examples  of  such  algorithms  include  DSA  for  digital 
signatures,  and  Dif f ie-Hellman  (DH)  .  L  is  the  size  of  the 
public  key,  and  N  is  the  size  of  the  private  key.  Column  4 
indicates  the  value  for  k  (which  corresponds  to  the  key 
size)  for  algorithms  based  on  integer  factorization. 
Finally,  Column  5  indicates  the  range  of  f  (the  size  of  n, 
where  n  is  the  order  of  the  base  point  G)  for  algorithms 
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based  on  elliptic  curves  that  are  specified  for  digital 
signatures.  The  value  of  f  is  commonly  referred  to  as  the 
key  size. 

3.  Processing  Overhead 

Closely  related  to  the  key  size  of  different  public 
key  systems  is  the  channel  overhead  required  to  perform  key 
exchanges  and  digital  signatures  over  a  network.  The  key 
sizes  for  public  keys  in  Table  1  of  Chapter  III  is  also 
roughly  the  number  of  bits  that  need  to  be  transmitted  each 
way  over  a  communications  channel  for  a  key  exchange. 
Although  in  the  case  of  ECC,  there  is  one  additional  bit 
that  needs  to  be  transmitted  in  each  direction,  which 
allows  the  recovery  of  both  the  x  and  y  coordinates  of  an 
elliptic  curve  point.  (National  Security  Agency  Central 
Security  Service,  2009) 

The  difficulty  of  the  ECDLP  algorithm  means  that 
relatively  strong  security  is  possible  with  smaller  key  and 
certificate  sizes.  The  smaller  key  size  in  turn  means  that 
less  EEPROM  is  required  to  store  keys  and  certificates  and 
that  less  data  needs  to  be  passed  between  the  card  and  the 
application  allowing  for  shorter  transmission  times. 

As  smart  card  applications  continue  to  require 

stronger  and  stronger  security  (via  longer  keys) ,  ECC  can 

continue  to  provide  adequate  security  with  fewer  additional 

system  resources.  In  other  words  ECC  smart  cards  are 

capable  of  providing  higher  levels  of  security  without 

increasing  their  cost.  ECCs  reduced  processing  times  also 

contribute  significantly  to  why  ECC  meets  the  smart  card 

platform  requirements  so  well.  By  comparison,  other  public 

key  systems  involve  so  much  computation  that  a  dedicated 
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hardware  device  known  as  a  crypto  coprocessor  is  often 
required.  This  crypto  coprocessor  not  only  takes  up  space, 
but  adds  about  20  to  30  percent  to  the  cost  of  a  chip 

(about  three  to  five  dollars  towards  the  cost  of  each 
card)  .  With  ECC,  the  algorithm  can  be  implemented  in 

available  ROM,  so  no  additional  hardware  is  required  to 

perform  strong,  fast  authentication.  (Certicom,  1998) 

Implementing  public  key  cryptography  in  a  smart  card 
application  poses  numerous  challenges.  Smart  cards  present 
a  combination  of  implementation  constraints  that  other 

platforms  do  not.  Constrained  memory  and  limited  computing 
power  are  two  of  them.  Current  DoD  CAC  cards  in  the  field 
today  have  between  about  IK  to  6K  of  RAM,  64  to  144 
kilobytes  of  EEPROM,  and  16  to  32  kilobytes  of  ROM  with  the 
traditional  8  to  16  bit  CPU  typically  clocked  at  Internal 
CPU  clock  up  to  30  MHz  with  synchronous  operation.  Any 
additional  requirements  of  memory  or  processing  capacity 
increase  the  cost  to  an  already  cost  sensitive  card.  Smart 
cards  are  also  slow  transmitters.  It  can  only  communicate 
a  maximum  of  255  bytes  per  Application  Protocol  Data  Unit 
(APDU)  transaction.  An  APDU  is  the  communication  unit 
between  a  smartcard  reader  and  a  smartcard.  In  order  to 
achieve  acceptable  application  speeds,  data  elements  must 
be  small  (to  limit  the  amount  of  data  passed  between  the 
card  and  the  terminal) .  While  cryptographic  services  that 
are  efficient  in  memory  usage  and  processing  power  are 
needed  to  contain  costs,  reductions  in  transmission  times 
are  also  needed  to  enhance  usability. 

Given  the  rigid  constraints  on  processing  power, 
parameter  storage,  and  code  space,  as  well  as  slow 
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input/output  associated  with  smart  cards  implementation  of 
public  key  cryptosystems  has  been  associated  with  high-end 
cards,  typically  with  both  large  memory  configurations  and 
cryptographic  coprocessors.  Certicom  Incs  ECC 
implementations  enable  the  deployment  of  lower  cost  smart 
cards  without  compromising  any  of  the  required  performance 
and  security  features.  ECC  smart  cards  would  not  require 
as  much  memory,  nor  would  they  require  a  cryptographic 
coprocessor  to  deliver  strong  authentication. 

In  Summary,  ECC  key  size  advantages  afford  many 
benefits  for  smart  cards,  and  the  superior  performance 
available  through  judicious  ECC  implementations  make 
applications  feasible  in  low  end  devices  without  the  need 
for  additional  dedicated  crypto  hardware.  In  channel- 
constrained  environments,  elliptic  curves  offer  a  much 
better  solution  than  first  generation  public  key  systems. 

G.  CONCLUSIONS  ON  RSA  AND  ECC 

In  very  general  terms,  elliptic  curve  cryptosystems 
offer  the  same  security  that  an  RSA  system  or  a  discrete 
logarithm  based  system  offers  but  with  significantly 
smaller  key  lengths.  In  terms  of  speed,  however,  it  is 
quite  difficult  to  give  a  quantitative  comparison.  This  is 
partly  due  to  the  various  optimization  techniques  that  can 
be  applied  to  different  systems.  Generally  elliptic  curve 
cryptosystems  are  faster  than  their  corresponding  discrete 
logarithm  based  systems.  Elliptic  curve  cryptosystems  are 
faster  than  the  RSA  system  in  signing  and  decryption,  but 
are  slower  in  signature  verification  and  encryption.  (RSA 
Security,  2004) 
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However,  ECC  implementation  could  have  a  significant 
impact  on  smaller  devices  such  as  PDAs  or  smart  cards  as 
the  relative  computational  performance  advantage  of  ECC 
over  RSA  is  not  indicated  by  key  sizes  but  by  the  cube  of 
the  key  sizes.  The  difference  becomes  even  more  dramatic 
as  the  increase  in  RSA  key  sizes  leads  to  an  even  greater 
increase  in  computational  cost.  Going  from  1024-bit  RSA 
key  to  3072-bit  RSA  key  requires  about  27  times  as  much 
computation  while  ECC  would  only  increase  the  computational 
cost  by  just  over  4  times  (Vanstone,  2004)  . 
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V.  IMPACT  OF  DOD  MIGRATION  TO  NSA  SUITE  B 


A.  INTRODUCTION 

Public  key  cryptography,  using  digital  certificates, 
offers  the  best  available  technology  for  secure 
transmission  of  unclassified  data  across  public  and  private 
networks.  It  provides  a  high  degree  of  assurance  of 
confidentiality,  integrity,  access  control,  and  user 
identification  among  users  of  networked  applications, 
including  e-mail,  Web-based  information  transactions,  and 
other  electronic  commerce.  The  DoD  PKI  refers  to  the 
framework  and  services  that  provide  for  the  secure 
generation,  production,  distribution,  control,  and 
accounting  of  DoD  public  key  certificates.  Its 
implementation  was  mandated  by  a  DoD  memorandum  from  the 
Department  of  Defense  dated  6  May  1999,  with  a  target 
completion  date  of  October  2004. 

Within  this  framework,  DoD  planners  have  worked  to 
gain  and  maintain  the  initiative  in  the  struggle  against 
those  entities  that  would  seek  to  benefit  from  breaches  of 
information  security.  With  this  in  mind,  the  DoD  and  the 
U.S.  Government  as  a  whole  face  a  paradigm  shift  from  the 
classical  discrete  logarithm  and  integer  factorization  key 
generation  techniques  now  in  widespread  use,  to  the  newer, 
more  creative  methods  of  elliptic  curve  cryptography. 
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B. 


CAC  ISSUANCE  TIMES 


One  of  the  primary  goals  of  the  DoD  PKI  is  to  reduce 
the  amount  of  time  required  for  the  CAC  issuance  process. 
Currently  with  RSA  1024  the  typical  issuance  time  falls 
within  a  three-  to  five-minute  window.  RSA  2048  is 

estimated  to  increase  the  time  by  an  average  of  nearly  two 

minutes.  If  this  trend  is  followed  (e.g.,  RSA  3072  and 
beyond)  the  issue  times  would  continue  to  increase  and 

perhaps  become  unacceptable.  Here  we  come  to  one  of  the 
fundamental  benefits  of  ECC  over  its  predecessors. 

As  was  shown  in  Chapter  IV,  CAC  issuance  using  ECC 

will  provide  a  significant  reduction  in  processing  time. 
According  to  the  information  contained  in  Table  3,  163-bit 

ECC  takes  3.8  milliseconds  to  generate  a  key.  Erom  the  RIM 
performance  comparison  in  Table  4/  we  see  also  that  256-bit 
ECC  takes  only  166  milliseconds.  It  is  difficult  to  say 
with  accuracy  how  long  key  generation  will  take  using  the 
limited  resources  on  a  CAC  card,  because  RIMs  BlackBerry  is 
a  faster,  more  capable  platform  compared  to  a  typical 
smartcard  chip,  and  because  163-bit  ECC  is  not  the  size 
recommended  by  NIST.  Regardless,  it  is  clear  that  even 
without  knowing  the  exact  key  generation  time  required  for 
ECC,  the  general  difference,  which  is  an  order  of  magnitude 
improvement,  is  significant. 

Erom  the  CAC  test  lab  studies  at  the  DMDC  mentioned  in 
Chapter  IV,  we  know  RSA  2048  key  generation  times  will  be 
approximately  45  seconds  per  key.  Multiply  this  number  by 
three,  which  is  the  number  of  keys  generated  on  a  CAC  (ID 
Certificate,  PIV  Authority  Certificate,  and  Signature 
Certificate)  and  the  reader  will  have  a  general  idea  of 


how  much  time  each  CAC  requires. 
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Time  savings  will  translate  to  higher  productivity. 
The  ability  to  produce  more  in  less  time  will  lead  to 
customer  satisfaction  and  ultimately  lower  costs.  Consider 
the  scenario  where  a  large  number  of  new  CAC  holders  need 
to  receive  their  cards  —  new  contractors  for  example.  A 
substantially  smaller  amount  of  time  will  be  necessary  to 
complete  the  CAC  issuance  process  for  each  new  individual. 

C.  EXISTING  INFRASTRUCTURE 

1 .  Current  DoD  PKI  Architecture 

According  to  the  Deputy  Secretary  of  Defense 
(DEPSECDEF)  memorandum  entitled  "Department  of  Defense 
Public  Key  Infrastructure,"  as  modified  by  the  DoD  Chief 
Information  Officer  (CIO)  on  12  August  2000,  there  were  at 
least  twelve  top-level  milestones  for  the  DoD  PKI.  The 
milestones  included  practical  items  like  certificate 
issuance  and  registration  infrastructure  deployment.  They 
also  contained  mission  essential  tasks  like  functional 
token  certificate  based  access  control  and  ensuring  the 
ability  to  appropriately  sign  emails. 

The  time  allocated  to  complete  the  year  2000 
milestones  was  approximately  four  years.  The  authors  of 
this  thesis  anticipate  that  the  transition  to  NSA  Suite  B 


will  be 

equally 

as  comprehensive. 

but 

that  the  time 

required 

to  fully 

integrate 

will  not 

be 

as  long  as 

the 

original 

transition  to  PKI 

systems . 

This  transition 

is 

expected 

to  be 

difficult 

due  mostly 

to  factors 

of 

interoperability,  which  will  be  addressed  to  some  degree  by 
the  modular  architecture  of  the  DoD  PKI.  (Information 
Assurance  Technology  Analysis  Center,  2000) 
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The  DoD  PKI,  which  evolved  from  the  DoD  Medium 
Assurance  Pilot  PKI,  supports  the  protection  of  business 
transactions  and  sensitive  but  unclassified  administrative 
information.  The  DoD  PKI  can  also  be  used  on  closed 
networks  like  SIPRNET  or  NIPRNET  to  provide  additional 
protection  such  as  user  authentication  and  data  separation. 
(Information  Assurance  Technology  Analysis  Center,  2000) 

DoD  PKI  service  employs  a  hierarchical  architecture 
consisting  of  a  centralized  Root  CA  with  a  single  level  of 
subordinate  CAs,  a  small  number  of  Registration  Authorities 
(RA) ,  and  a  larger  number  of  Local  Registration  Authorities 
(LRA)  .  Currently  LRAs  function  at  RAPIDS  stations,  and 
certificates  are  able  to  be  installed  on  DoD  CACs . 
(Information  Assurance  Technology  Analysis  Center,  2000) 

Given  this  existing  infrastructure,  a  great  deal  of 
planning  is  necessary  in  order  to  implement  a  new 
cryptographic  suite. 

2.  DoD  PKI  Hardware  and  Software 

The  DoD  PKI  PMO  procures  all  hardware  required  for  PKI 
implementation  at  the  Root  and  CA  levels.  At  the  lower 
levels  the  various  services  or  governmental  agencies  are 
responsible  for  acquiring,  installing,  accrediting, 
operating,  and  maintaining  components  associated  with  PKI. 
(Information  Assurance  Technology  Analysis  Center,  2000) 

Currently,  the  DMDC  has  deployed  integrated  RAPIDS 
workstations  at  approximately  2,000  DoD  RAPIDS  stations  at 
various  locations  around  the  world.  These  integrated 
RAPIDS  workstations  were  meant  to  support  the  issuance  of 
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the  four  certificates  (only  three  of  which  are  generated 
inside  the  DoD  CAC)  to  all  military,  civilian,  and  selected 
contractor  personnel. 

Each  RAPIDS  station  is  manned  with  a  Verification 
Officer  (VO) .  All  of  these  VOs  will  require  updated 
training,  as  well  as  replacement  CACs  with  updated  ECO 
standards.  CAC  replacement  is  necessary  because  in  order 
to  issue  ECC  certificates  the  issuer  must  possess  a 
sufficient  security  level.  Additionally,  all  2,000 

workstations  will  need  to  be  updated  to  support  ECC.  This 
process  will  be  exacerbated  by  the  fact  that  the  stations 
are  deployed  around  the  globe. 

a.  Implementation  at  the  Local  Commands 

Where  applications  employing  public  key 
technology  are  required,  the  local  commands  and  DoD 
organizational  elements  are  responsible  for  developing  and 
deploying  public  key  enabled  applications  (or  integrating 
commercially  available  PK  enabled  products)  that  are 
compatible  and  compliant  with  the  DoD  PKI .  In  accordance 
with  DEPSECDEE  memorandum  dated  12  August  2000,  all  the 
former  PK  enabled  applications  have  been  transitioned  so 
that  they  are  DoD  PKI  compliant.  Additionally,  all  Web 
servers  have  been  PK  enabled  to  perform  server-side 
authentication  using  SSL  Authentication  and  DoD  public  key 
certificates.  Currently,  the  vast  majority  of  DoD  Web 
servers  are  capable  of  performing  client-side 
authentication  using  DoD  CAC  certificates.  (DoD  Public  Key 
Infrastructure  Program  Management  Office,  2000) 

To  date,  all  active  duty  military  personnel, 

members  of  the  Selected  Reserve,  DoD  civilian  employees, 
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and  eligible  contractor  personnel  who  require  access  to  DoD 
systems  have  received  their  PKI  certificates  on  a  DoD  CAC 
(over  10  million  since  2002)  .  Although  DMDC  installed  the 
upgraded  integrated  RAPIDS  workstation  at  its  RAPIDS 
locations,  the  responsibility  for  issuing  DoD  CACs  remains 
with  the  DoD  organizations  operating  the  RAPIDS  stations. 
For  most  services,  the  DoD  RAPIDS  stations  are  typically 
located  at  local  Personnel  Support  Detachment  (PSD) ,  Pass  & 
ID,  or  Security  offices.  Individual  departments  were  left 
with  the  responsibility  to  develop  specific  plans  and 
identify  any  additional  resources  needed  to  support 
certificate  and  CAC  issuance.  (DoD  Public  Key 
Infrastructure  Program  Management  Office,  2000) 

Here  the  impact  of  implementation  of  NSA  Suite  B 
is  that  the  local  commands  will  now  be  responsible  for 
integration  within  their  current  command  specific  CAC 
enabled  applications.  This  will  be  costly  in  terms  of  re¬ 
design,  testing,  development  and  integration.  If  the  new 
methods  do  not  work  a  hybrid  solution  will  have  to  be 
looked  at  which  will  be  discussed  at  length  in  Chapter  VI. 
All  of  this  will  lead  to  potentially  significant  costs  in 
time  and  money. 

b.  DoD  Certification  Authority 

The  agency  responsible  for  all  aspects  of  the  DoD 
PKI  is  the  DoD  PKI  Program  Management  Office  (PMO)  .  DoD 
PKI  PMO  coordinates  all  component  and  system  development 
and  testing  through  the  efforts  of  its  three  working 
groups.  The  DoD  PKI  Technical  Working  Group  is  responsible 
for  identifying,  addressing,  and  resolving  technical  and 
operational  issues  associated  with  the  implementation  and 
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operation  of  the  DoD  PKI .  The  DoD  PKI  Business  Working 
Group  is  responsible  for  addressing  DoD  PKI  business 
requirements.  The  DoD  PKI  Certificate  Policy  Management 
Working  Group  (CPMWG)  is  responsible  for  preparing  and 
coordinating  the  DoD  Certificate  Policy  (CP) ,  including  the 
creation,  review,  and  update  of  all  relevant  documentation. 

The  NSA,  supported  by  DISA,  serves  as  the  DoD  PKI 
PMO  as  directed  by  the  Assistant  Secretary  of  Defense  for 
C4I,  and  provides  coordination  of  activities  across  the  DoD 
to  define  and  implement  the  DoD  PKI.  The  PMO  provides  the 
leadership  and  coordination  for  all  PKI  activities  across 
the  Department,  and  is  the  single  point  of  responsibility 
for  all  DoD  PKI  planning,  development,  and  implementation 
activities.  The  DoD  PKI  PMO  is  responsible  for  overall 
program  management  of  all  DoD  efforts  required  to  execute 
the  DoD  PKI  transition.  The  PMO  is  also  responsible  for 
raising  awareness  of  the  status  of  ongoing  and  planned  PKI 
related  activities,  and  the  support  that  is  available  for 
their  effective  use.  (DoD  Public  Key  Infrastructure  Program 
Management  Office,  2000) 

The  impact  of  migration  at  this  level  will  be  the 
scope  of  the  broad  planning  efforts  required.  NSA  will 
need  to  continue  to  liaison  with  DISA,  and  DISA  will  have 
to  maintain  communications  with  the  DMDC  in  order  to 
receive  and  deliver  guidance  and  progress  reports.  In 
addition  to  the  large  scale  coordination  efforts  required, 
the  monetary  costs  associated  with  renewed  licensing,  third 
party  consulting  fees  and  the  myriad  other  miscellaneous 
expenses  that  will  arise  will  have  an  impact. 
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D .  MIGRATION  COSTS 


In  order  to  stay  relevant  the  DoD  PKI  structure  must 
continually  evolve  over  time,  and  the  PKI  Program  has 
established  a  fundamental  philosophy  for  these  transitions. 
Enhanced  system  capabilities  must  be  introduced  in  parallel 
with  existing  operational  capabilities.  Every  effort  will 
have  to  be  made  to  ease  the  operational  impact  to 

subscribers  resulting  from  the  evolution  of  infrastructure 
capabilities.  Whenever  feasible,  the  transition  strategy 
should  not  be  based  on  hard  cutovers.  This  will  allow 
subscribers  to  plan  and  implement  effective  transitions  of 
their  operations  to  take  advantage  of  the  newest 
capabilities . 

The  DoD  PKI  has  adopted  a  highly  modular,  nodal 

architecture  for  the  evolving  DoD  key  management 

infrastructure.  The  architecture  is  built  on  four  types  of 
nodes.  The  first  is  the  Client  Node,  which  represents  the 
subscribers  that  require  products  and  services  from  the 
PKI.  The  next  node  is  the  Primary  Services  Node  (PRSN)  . 
The  PRSN  is  the  core  element  of  the  PKI  structure, 

providing  common  management  functions  in  a  server-based 
architecture.  It  offers  client  nodes  access  to  the 
production  sources,  providing  direct  delivery  of  PKI 
products  and  services  to  applications  that  require  them. 
It  also  handles  subscriber  access  control  and  manages  the 
interfaces  between  the  other  nodes.  The  third  node  is  the 
Production  Source  Nodes  (PSNs) ,  which  interfaces  to  the 
common  management  functions  of  the  PRSN  (e.g.,  the  PKI  CA 
that  provides  certificate  management  functions  such  as 
certificate  creation,  posting,  rekeying,  and  revocation) . 
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Finally,  the  Central  Services  Node  (CSN)  provides  overall 
system  management  and  configuration  management  functions 
for  the  infrastructure,  including  the  long-term  system 
archive  and  the  master  key  management  infrastructure 
database.  The  CSN  also  handles  system  health  monitoring 
and  overall  infrastructure  security  management,  including 
intrusion  detection  security  oversight  and  audit  data  and 
analysis.  (DoD  Public  Key  Infrastructure  Program  Management 
Office,  2000) 

By  enforcing  modularity  while  maintaining  control  of 
both  physical  and  functional  interfaces,  PKI  features  and 
capabilities  are  theoretically  set  up  to  evolve  over  time 
in  a  structured  and  cost  effective  manner,  which  will 
facilitate  an  eventual  cutover  to  Suite  B. 

1.  DoD  PKI  5.0 

As  indicated  earlier,  the  DoD  PKI  evolution  is 
designed  to  offer  PKI  products  and  services  with  a 
transition  transparent  to  subscribers.  The  detailed  design 
and  planning  for  this  evolution  is  extensive,  but  the 
evolutionary  strategy  is  fairly  straightforward. 

The  Medium  Assurance  PKI  pilot  was  transitioned  to  the 

Class  3  PKI  (Release  1.0)  in  April  1998.  In  July  2000,  the 

DoD  Class  3  PKI  (Release  2.0),  which  introduced  the  use  of 

newer  certificates  was  approved  for  operational  use. 

Efforts  to  incorporate  PKI  LRA  functionality  into  RAPIDS 

terminals  were  completed.  These  updated  RAPIDS  terminals 

were  introduced  in  Class  3  PKI  Release  3.0  to  provide  a 

means  for  registering  users  enrolled  in  DEERS  into  the  PKI 

and  issuing  CACs  (smart  cards)  that  serve  as  PKI  hardware 

tokens.  The  Class  3  PKI  Release  3.0  will  also  continue  to 
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support  certificates  in  software.  PKI  Release  4.0  provides 
an  initial  set  of  Class  4  (Defense  Messaging  System  or  DMS) 
PKI  products  and  services  consistent  with  those  provided  by 
the  existing  Class  3  PKI.  (DoD  Public  Key  Infrastructure 
Program  Management  Office,  2000) 

The  basic  definition  for  DoD  PKI  Release  5.0  includes 
support  for  access  control  mechanisms  that  enables  the 
transition  of  DMS  organizational  messaging  subscribers  to 
the  DoD  PKI.  It  will  introduce  an  initial  set  of  trusted 
date  and  trusted  time  stamp  services.  It  will  provide  an 
initial  capability  for  integrity/sof tware  download 
certificates.  It  will  allow  additional  support  for  new  Key 
Exchange  and  DSA  algorithms  (like  ECC)  .  Einally,  it  will 
provide  toolkits  for  PKI-aware  applications.  (DoD  Public 
Key  Infrastructure  Program  Management  Office,  2000) 

a.  Infrastructure  Management 

DoD  PKI  Release  5.0  will  provide  regional 
deployments  of  PKI  Primary  Service  Nodes.  It  will  allow 
for  the  ability  to  create  new  roles  and  dynamic  mapping  of 
privileges  to  those  roles.  It  will  create  enhance  existing 
PKI  Help  Desk  features  including  an  expanded  repository  of 
PKI  information  with  on-line  access  available  to  authorized 
users.  Its  external  interoperability  will  be  expanded  to 
approved  Allied  and  Coalition  partner  PKIs.  It  will 
integrate  Class  3  and  4  PRSN  structures.  Einally,  it  will 
incorporate  an  independent  CSN  with  electronic  access  to 
all  PRSNs.  (DoD  Public  Key  Infrastructure  Program 
Management  Office,  2000) 
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b.  Anticipatory  Developments 

There  are  a  number  of  additional  PKI  related 
activities  that  are  substantial  in  order  to  accomplish  the 
5.0  Release.  These  activities  are  intended  to  ensure  the 
smooth  progression  of  PKI  capabilities.  Among  them  is  the 
development  of  an  audit  reduction  tool,  implementation  of 
the  EC  algorithm,  and  the  development  of  a  key  management 
Applications  Programming  Interface  (API).  Additionally, 
time  stamp  application  and  processing,  and  prototype 
automated  accounting  and  archive  capabilities.  Release  5.0 
will  also  be  used  to  enhance  the  tactical  aspects  of  DoD 
PKI  to  include  a  tactical  network  model,  protocol 
simulators  and  demand  simulators.  Release  5.0  will  also 
act  as  an  integration  tool  to  ease  into  the  Release  6.0 
transition  by  merging  a  prototype  deployable  PRSN  and  a  PSN 
simulator  for  new  algorithms  as  well  as  prototype  Class  5 
PKI  PRSN  and  PSN  capabilities.  As  always,  these 

prototyping  activities  are  subject  to  the  availability  of 
funds  and  are  subject  to  the  priorities  that  are 
established  at  the  time  of  their  initiation.  (DoD  Public 
Key  Infrastructure  Program  Management  Office,  2000) 

2 .  Money 

a.  Hardware  Replacement 

Most  of  the  core  infrastructure  components 

associated  with  the  PKI  (i.e.,  RAs,  directory  components 

and  LRAs)  are  already  in  place  within  the  DoD.  Currently 

LRA  functional  capability  at  the  DoD  RAPIDS  stations  is 

nominal.  The  oversight  of  the  operation  of  LRAs,  and 

issuance  of  CACs  and  Smart  Card  readers,  via  DEERS/RAPIDS 

is  also  already  in  place.  Einally,  additional  LRAs  beyond 
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those  provided  by  DoD  RAPIDS  stations  have  been  established 
and  can  provide  RA/LRA  operations,  maintenance,  and  life 
cycle  support  (Information  Assurance  Technology  Analysis 
Center,  2000) . 

The  implementation  of  ECC  itself  will  not  require 
any  significant  hardware  updates.  Currently  planned 
hardware  refreshment  plans  will  be  sufficient  and  should 
remain  unaffected  by  the  migration.  The  only  real  hardware 
that  will  have  to  be  replaced  across  the  board  is  the 
actual  cards  that  are  issued  to  DoD  personnel  but  even  that 
will  occur  within  the  normal  replacement  cycles,  which  will 
be  facilitated  by  the  phased  transition  approach. 

b.  Infrastructure  Upgrade 

The  PKI  PMO  has  the  task  of  identifying  toolkits 
and  ensuring  they  are  available  to  facilitate  the 
interaction  and  customer  support  for  programs  and  vendors 
that  are  actually  performing  PKI  transitions.  DISA  will 
lead  activities  to  identify  and  evaluate  the  effectiveness 
of  commercial  PKI  toolkits.  NSA  will  take  the  lead  for 
developing  specialized  toolkits  needed  to  address  specific 
requirements  that  cannot  be  satisfied  from  the  private 
sector.  DISA  Joint  Integration  and  Testing  Command  (JITC) 
has  been  established  as  a  PK  enabled  applications  test 
facility  for  developers  and  integrators  to  verify 
compliance  and  compatibility  of  their  implementations 
within  the  PKI.  All  DoD  services  and  agencies  will  retain 
the  responsibility  for  enabling  their  applications  and 
devices  to  be  compatible  with  current  PKI  capabilities. 


including  the  funding  needed  to  maintain  and  operate  the 
test  facilities.  (NIST  Information  Technology  Laboratory, 
2000) 

The  DMDC  is  responsible  for  the  development  and 
upgrade  of  RAPIDS  terminals  to  incorporate  the 
functionality  and  establish  operations  needed  for  them  to 
serve  as  LRAs  for  the  PKI .  The  DMDC  would  perform  the 
RAPIDS  development  activities. 

c.  Refresh  Plan 

The  PKI  PMO  will  assume  overall  responsibility 
for  procuring,  or  directing  the  procurement  of  all 
centrally  operated  infrastructure  elements.  The  PKI  PMO 
will  develop  the  acquisition  strategy  for  any  significant 
changes  to  the  DoD  PKI.  Concurrently,  NSA  and  DISA  will 
procure,  develop,  or  direct  the  procurement  of  the 
centrally  operated  infrastructure  elements  of  the  key 
management  infrastructure.  DISA  will  also  be  responsible 
for  the  procurement  and  deployment  of  centralized  directory 
elements  of  the  PKI.  The  DoD  PKI  PMO  will  develop  the 
acquisition  strategy  for  the  DoD  PKI,  the  certificate 
management  components  and  services  as  well  as  the  refresh 
plan.  DISA  is  the  lead  for  the  integration  of  the 
centralized  components  of  the  PKI,  including  the  CA  servers 
and  directory  components.  The  services  and  agencies  will 
procure  local  infrastructure  elements,  PKI  RA  and  LRA 
workstations  and  local  directories. 
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VI.  MANAGING  RISK 


A.  INTRODUCTION 

Assuming  DoD  will  eventually  wholly  migrate  to  Suite 

B,  risk  management  will  play  a  large  role  in  the  successful 
transition.  The  purpose  of  this  chapter  is  to  identify 
risk  and  then  make  some  educated  recommendations  on  how  to 
best  mitigate  those  risks. 

B.  METHODOLOGY 

Within  this  chapter,  we  intend  to  review  the  RSA  1024 
to  RSA  2048  Migration  Plan.  From  this  plan,  we  will 
evaluate  the  lessons  learned.  This  information  will  then 
be  factored  into  the  creation  of  an  original  critical  path 
analysis  for  the  RSA  to  ECC  transition. 

Also  within  this  chapter,  we  will  identify  some  of  the 
other  potentially  high  risk  areas  associated  with 
development,  deployment  and  operation  of  NSA  Suite  B  within 
the  DoD  framework.  Recognizing  that  effective  risk 

management  is  critical  to  the  success  of  any  program,  we 
break  it  down  into  its  two  fundamental  parts;  assessment 
and  mitigation. 

C.  NSA  SUITE  B  MIGRATION  RISKS 

1 .  Proprietary  Complications 

As  a  way  of  clearing  the  way  for  the  implementation  of 
elliptic  curves  to  protect  US  and  allied  government 
information,  the  National  Security  Agency  purchased  a 
license  from  Certicom  Inc.  that  covers  all  of  their 
intellectual  property  in  a  restricted  field  of  use.  The 
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license  would  be  limited  to  implementations  that  were  for 
national  security  uses  and  certified  under  FIPS  140-2  or 


were  approved  by  NSA.  Further,  the  license  would  be 
limited  to  only  prime  field  curves  where  the  prime  was 
greater  than  2255.  On  the  NIST  list  of  curves  3  out  of  the 
15  fit  this  field  of  use:  the  prime  field  curves  with 
primes  of  256  bits,  384  bits  and  521  bits.  Certicom  Inc. 
identified  26  patents  that  covered  this  field  of  use.  NSAs 
license  includes  a  right  to  sublicense  these  26  patents  to 
vendors  building  products  within  the  restricted  field  of 
use.  Certicom  Inc.  also  retained  a  right  to  license 
vendors  both  within  the  field  of  use  and  under  other  terms 
that  they  may  negotiate  with  vendors.  (Certicom,  2000) 

a.  Local  Level  Challenges 

As  previously  alluded  to  in  Chapter  V,  local 
commands  will  be  responsible  for  their  command  specific  CAC 
enabled  applications.  This  will  present  some  unique 
challenges  due  to  the  newness  of  the  technology.  Local 
Commands  will  face  application  upgrade  issues  in  terms  of 
hiring  subject  matter  experts  who  will  be  necessary  to 
facilitate  the  software  upgrades.  Moreover,  they  may  have 
to  deal  with  the  patent  issues  associated  with  Certicoms 
commercial  ownership  of  ECC. 

2.  Software  Compatibility 

Less  than  a  year  prior  to  the  publication  of  this 
thesis,  Windows  announced  that  its  Vista  Service  Pack  1  and 
Windows  Server  2008  would  support  Suite  B  cryptographic 
algorithms  as  a  part  of  its  Cryptography  Next  Generation 
(CNG) .  For  Windows  7.0  and  Server  2008  R2,  TLS  and 
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Encrypting  File  System  (EES)  will  be  implemented  using 
Suite  B  algorithms.  Currently  CNG  is  not  FIPS  140-2  level 
2  certified,  nor  is  it  Common  Criteria  certified,  which 
prohibits  its  use  within  the  DoD.  FIPS  140-2  precludes  the 
use  of  un-validated  cryptography  for  cryptographic 
protection  of  sensitive  data  within  the  federal  system. 
Invalidated  cryptography  is  viewed  by  NIST  as  providing  no 
protection  to  the  information  or  data  -  in  effect  the  data 
would  be  considered  unprotected  plaintext.  If  the  agency 
specified  that  information  or  data  be  cryptographically 
protected,  then  FIPS  140-2  is  applicable,  and  if 
cryptography  is  required,  it  must  be  validated.  (NIST 
Information  Technology  Laboratory,  2009) 

With  the  passage  of  the  Federal  Information  Security 

Management  Act  (FISMA)  of  2002,  there  is  no  longer  a 
statutory  provision  to  allow  agencies  to  waive  mandatory 
FIPS.  The  waiver  provision  had  been  included  in  the 

Computer  Security  Act  of  1987;  however,  FISMA  superseded 
that  act . 

Although  the  latest  versions  of  Windows  applications 

are  in  the  process  of  incorporating  Suite  B  for  use  within 
the  DoD,  earlier  versions  will  not  be  retroactively 
upgraded.  For  example,  Windows  XP  and  Server  2003  will  not 
be  supported  and  will  eventually  have  to  be  phased  out  of 
use  as  Suite  B  incrementally  supplants  older  methods. 

3.  RSA  Critical  Path  Analysis 

We  will  be  using  the  Critical  Path  Method  (CPM)  or 

Critical  Path  Analysis  to  analyze  former  DoD  migration 

projects  to  provide  perspective  on  the  migration  to  Suite 

B.  We  will  also  create  Network  Planning  Diagrams,  which 
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are  very  effective  planning  tools  for  unique  projects  that 
contain  interactions  between  several  components  with  many 
interrelated  tasks.  CPM  is  also  an  effective  procedure  for 
using  network  analysis  to  identify  those  tasks  on  the 
critical  path,  which  have  the  potential  to  lengthen  the 
overall  project  timescale.  For  most  deviations  from  the 
critical  path  (late  starts,  early  starts,  etc.)  there  is  a 
degree  of  tolerance  within  which  project  success  is  still 
likely . 


a.  RSA  1024  to  RSA  2048  Lessons  Learned 

The  major  tasks  that  must  be  completed  on  time 
for  the  migration  of  RSA  1024  to  RSA  2048  are  outlined  in 
Table  9  below. 


Desc: 

ription 

Required 

Predecessor 

Duration 

(Weeks) 

1. 

Develop  Migration  Process  for  Software 

1 

2. 

CAC  Enable  Application  Testing 

21 

3. 

CA  Upgraded 

38 

4. 

Sample  Alpha  Cards  Received 

27 

5. 

Go  Through  FIPS  Certification 

6. 

Update  CAC  Infrastructure  Software 

1 

17 

7. 

Server  Test  Upgrade 

1 

21 

8. 

RAPIDS  Upgrade 

1 

20 

9. 

Applet/Card  Integration  Test 

4 

2 

10. 

Infrastructure  software  Install  / 

Patch  update 

6 

20 

11 . 

CAC  Enable  Application  Test 

8 

6 

12  . 

Provide  Server  Certificates 

3 

1 

13. 

Test  CA 

3 

5 

14  . 

CAC  Infrastructure  Integration  Test 

10 

1 

15. 

Deploy  New  Server 

15 

2 

16. 

Install  Server  Certs 

12 

2 
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17  . 

Alpha  Card  Internal  Testing 

9 

11 

18  . 

Alpha  Card  Customer  Testing 

17,  12 

4 

19. 

CAC  Infrastructure  Deploy  to  Test 
Environment 

14 

1 

20. 

CAC  Issuance  Integration  Test 

15,  11,  16, 

19 

2 

21 . 

Order  Beta  Cards 

9 

13 

22  . 

Performed  new  Card  Keys  Ceremony 

21 

2 

23. 

Issue  Beta  Card 

20,  13,  22 

1 

24  . 

Beta  Card  Testing 

23 

9 

25. 

Approve  for  Production 

24,  5 

1 

Table  9.  Critical  Tasks  for  RSA  1024  to  RSA  2048 


From  this  table  a  network  activity  diagram  was 
created  that  shows  the  dependent  sequence  of  activities. 
In  the  diagram,  a  network  of  tasks  is  set  up  to  show  which 
need  completion  before  other  tasks  can  be  started.  This 
helps  to  identify  the  critical  path,  which  is  the  route 
through  the  network  that  will  take  the  most  time.  If  there 
are  more  than  one  predecessor  tasks,  then  there  will  be 
several  possible  early  starts.  The  largest  of  these  is  the 
most  important.  The  early  finish  for  each  task  is  equal  to 
the  early  start  plus  the  task  duration.  The  final 

calculation  is  for  the  earliest  completion  time  for  the 
project.  This  is  calculated  like  the  early  start  date. 
Starting  with  the  tasks  at  the  end  of  the  diagram, 
calculate  the  late  start  and  late  finish  for  each  task  in 
turn,  following  the  arrows  in  the  reverse  direction,  as  in 
Figure  11  below. 
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Figure  11.  RSA  1024  to  RSA  2048  Critical  Path 

The  late  finish  is  the  same  as  the  late  start  of 
the  succeeding  task  (for  the  final  tasks  in  the  project, 
this  is  equal  to  the  earliest  completion  date) .  If  there  is 
more  than  one  successor  task,  then  there  are  several 
possible  late  tasks.  We  select  the  smallest  of  these.  The 
late  start  for  each  task  is  the  late  finish  minus  the  task 
duration.  The  final  calculation  is  for  the  earliest 
completion  time  for  the  project.  This  is  calculated  in  the 
same  way  as  the  early  start  date.  We  calculate  slack  time 
by  subtracting  the  early  start  from  the  late  start.  The 
slack  time  is  the  amount  of  time  the  task  can  be  slipped 
without  affecting  the  end  date.  Tasks  on  the  critical  path 
have  no  slack. 
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CAC  Infrastructure 
Integration  Test 

10 

1 

Deploy  New  Server 

15 

2 

Install  Server 

Certs 

12 

2 

Alpha  Card 

Internal  Testing 

9 

11 

Alpha  Card 

Customer  Testing 

17,  12 

4 

CAC  Infrastructure 
Deploy  to  Test 
Environment 

14 

1 

CAC  Issuance 
Integration  Test 

15,  11,  16, 

19 

2 

Order  Beta  Cards 

9 

13 

Performed  new  Card 
Keys  Ceremony 

21 

2 

Issue  Beta  Card 

20,  13,  22 

1 

Beta  Card  Testing 

23 

9 

Approve  for 
Production 

24,  5 

1 

Table  10 


Critical 


sks  for  RSA  to  ECC 


4. 


ECC  Critical  Path  Risk  Analysis 


Based  on  the  nature  of  the  risks  identified  earlier, 
an  estimate  of  the  duration  of  each  activity  associated 
with  Suite  B  migration  is  possible.  The  activities  were 
each  given  three  time  estimates.  In  so  doing,  uncertainty 
in  completion  time  is  accounted  for  to  an  acceptable 
degree.  This  is  accomplished  by  using  the  following 
formula : 

te=  (  (to+4  (tm)  +tp)  )  /6 

Optimistic  Time  (to)  is  the  time  in  which  any 
particular  activity  may  be  completed  if  everything  goes 
well  and  there  are  no  complications.  Most  Likely  Time  (tm) 
is  the  time  in  which  a  particular  activity  can  most  often 
be  completed  under  normal  conditions.  If  an  activity  is 
repeated  many  times,  the  duration  of  time  to  accomplish 
this  activity  that  occurs  most  often  would  be  equivalent  to 
the  most  likely  time  estimate.  Pessimistic  time  (tp)  is 
the  time  in  which  a  particular  activity  may  be  completed 
under  adverse  conditions,  such  as  having  unusual  and 
unforeseen  complications.  (Gido,  1985) 

It  may  be  possible  to  reduce  the  critical  path  of  a 
project  (and  consequently  pull  in  the  completion  date)  by 
rearranging  some  tasks,  which  have  an  optional  sequence  or 
by  moving  key  personnel  into  tasks  in  the  critical  path. 

Our  prediction  for  the  migration  from  RSA  to  ECC  is 
that  the  lack  of  applications  that  are  ready  for  Suite  B 
implementation  and  the  lack  of  completed  field  testing  will 
be  a  major  factor  in  the  prolonging  of  the  completion  of 
Suite  B  migration. 
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Figure  12  and  Table  11  below  illustrate  the  related 
critical  path  and  essential  tasks. 


Figure  12.  RSA  to  ECC  Critical  Path 


Task 

Name 

Description 

Duration 

(Weeks) 

RSA 

te 

to 

tm 

tp 

Early 

Start 

(ES) 

Early 

Finish 

(EF) 

Late 

Start 

(LS) 

Late 

Finish 

(LF) 

Slack 

1. 

Develop 

Migration 

Process  for 
Software 

1 

2.00 

1 

2 

3 

0 

2 

9 

10 

9 

2. 

CAC  Enable 
Application 

Testing 

21 

30.17 

21 

30 

40 

0 

30 

15 

36 

15 

3. 

CA  Upgraded 

38 

38.00 

36 

37 

44 

0 

38 

9 

47 

9 

4. 

Sample  Alpha 
Cards  Received 

27 

27.17 

26 

27 

29 

0 

27 

1 

28 

1 

5. 

Go  Through 

FIPS 

Certification 

39 

39.33 

38 

39 

42 

0 

39 

38 

77 

38 

6. 

Update  CAC 
Infrastructure 
Software 

17 

17.33 

15 

17 

21 

1 

18 

11 

28 

10 
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7. 

Server  Test 
Upgrade 

21 

21.17 

19 

21 

24 

1 

22 

27 

48 

26 

8. 

RAPIDS 

Upgrade 

20 

20.17 

18 

20 

23 

5 

25 

10 

30 

5 

9. 

Applet/Card 
Integration  Test 

2 

2.33 

2 

2 

4 

27 

29 

28 

30 

1 

10. 

Infrastructure 
software  Install  / 
Patch  update 

20 

20.00 

19 

20 

21 

18 

38 

28 

48 

10 

11. 

CAC  Enable 
Application  Test 

6 

20.00 

15 

20 

25 

30 

50 

30 

50 

0 

12. 

Provide  Server 
Certificates 

1 

1.17 

1 

1 

2 

38 

39 

47 

48 

9 

13. 

Test  CA 

5 

5.17 

4 

5 

7 

38 

43 

50 

55 

12 

14. 

CAC 

Infrastructure 
Integration  Test 

1 

1.17 

1 

1 

2 

38 

39 

48 

49 

10 

15. 

Deploy  New 
Signing  Server 

2 

2.17 

2 

2 

3 

22 

24 

48 

50 

26 

16. 

Install  Server 

Certs 

2 

3.00 

2 

3 

4 

39 

42 

39 

42 

0 

17. 

Alpha  Card 

Internal  Testing 

11 

11.17 

10 

11 

13 

29 

40 

30 

41 

1 

18. 

Alpha  Card 
Customer 

Testing 

4 

4.33 

3 

4 

7 

40 

44 

53 

57 

13 

19. 

CAC 

Infrastructure 
Deploy  to  Test 
Environment 

1 

2.00 

1 

2 

3 

39 

41 

49 

50 

10 

20. 

CAC  Issuance 
Integration  Test 

2 

5.00 

4 

5 

6 

50 

55 

50 

55 

0 

21. 

Order  Beta 

Cards 

13 

13.17 

12 

13 

15 

29 

42 

40 

53 

11 

22. 

Performed  new 
Card  Keys 
Ceremony 

2 

2.33 

2 

2 

4 

42 

44 

53 

44 

11 

23. 

Issue  Beta  Card 

1 

2.00 

1 

2 

3 

55 

57 

55 

57 

0 

24. 

Beta  Card 

Testing 

9 

20.00 

9 

19 

35 

57 

77 

57 

77 

0 

25. 

Approve  for 
Production 

1 

1.33 

1 

1 

3 

77 

78 

77 

78 

0 

Table  11.  RSA  to  ECC  Critical  Tasks 


D.  RISK  MITIGATION 

1 .  Incremental  Implementation 

Much  of  the  required  infrastructure  that  supports 
everyday  applications  within  DoD  (e.g.,  Kerberos,  Smart 
Card  logon,  S/MIME)  is  not  fully  Suite  B  supported.  To 
date  one  of  the  few  major  protocols  that  are  fully 
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supported  is  TLS/SSL  (Microsoft,  2009)  .  That  being  the 
case,  TLS  is  an  ideal  place  to  start  the  incremental 
transition . 

According  to  Bob  Lord,  Senior  Engineering  Director  at 
Redhat  TLS  is  primed  for  initial  migration  activities 
because  it  provides  the  fewest  unpredictable  variables. 
Specifically,  servers  are  under  the  direct  control  of  their 
owners.  Additionally  some  newer  browsers  are  already  ECC 
enabled.  By  comparison,  clients  are  more  widespread  and 
have  many  more  varieties  of  requirements  and  policy 
constraints,  which  make  them  unlikely  candidates  to  be  a 
starting  point.  (Lord,  2009) 

2.  Software  Upgrade  Cycles 

As  a  best  practice  for  maintaining  the  highest  levels 
of  security,  it  is  recommended  that  the  latest  version  of  a 
given  browser  (e.g.  Internet  Explorer,  Eirefox)  is  used  for 
all  Web-based  applications. 

3 .  Pilot  Programs 

When  top-level  changes  are  implemented  —  like  the 
cryptographic  migration  of  RSA  to  ECC  —  it  is  always 
prudent  to  start  with  a  relatively  small,  controlled 
environment  in  which  to  test  the  new  technology  so  that 
there  is  less  risk  of  unforeseen  consequences. 

The  lessons  learned  from  pilot  programs  can  be 
invaluable.  Mistakes  that  occur  on  a  relatively  small 
scale  can  prevent  system  wide  failures  that  would  have  more 
severe  consequences. 
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The  authors  of  this  thesis  highly  recommend  an  ECC 
pilot  program  similar  to  the  Medium  Assurance  Pilot  program 
that  led  to  the  eventual  implementation  of  DoD  PKI . 

4.  Re source /Funding  Allocation 

Funding  availability  is  always  a  potential  risk  when 
dealing  with  major  government  programs.  Much  of  the 
responsibility  for  ensuring  that  PKI  related  programs 
receive  their  funding  will  fall  to  the  PKI  PMO.  The  PMO 
must  coordinate  with  the  various  agencies  (NSA,  DISA,  etc.) 
and  services  (USA,  USMC,  USN,  USAF,  etc.)  involved  to 
identify  resources  needed  to  complete  the  development  of 
the  architecture,  perform  security  analysis  and  testing  as 
well  as  procurement.  It  must  also  coordinate  to  identify 
funding  and  resources  needed  to  deploy  and  operate  the 
local  infrastructure  elements.  All  of  these  tasks  will  go 
towards  ensuring  that  funding  is  effectively  allocated  for 
specific  PKI  related  activities  like  migration  to  NSA  Suite 
B. 


5 .  Near  Term  Migration  Path 
a.  Legacy  Systems 

Some  legacy  systems  will  not  be  able  to  make  the 
move  to  ECC  due  mostly  to  the  fact  that  there  are  too  many 
deployed  clients.  This  issue  of  deployment  will  prevent  a 
quick  upgrade  to  ECC.  Many  clients  are  not  under  direct 
control  because  they  fall  under  the  local  command 
authority.  When  local  priorities,  logistics,  budgets, 
schedules  and  overall  lack  of  resources  are  considered, 
complete  upgrades  will  often  become  easy  targets  for 
commanders  looking  to  balance  multiple  needs.  For  example. 
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The  U.S.  Navys  fleet  used  Windows  NT  long  after  the  rest  of 
the  DoD  had  transitioned  to  Windows  2000/XP  because 
widespread  compatibility  issues  on  sensitive  systems.  A 
similar  decision  now  would  have  significant  implications  as 
the  DoD  transitions  to  NSA  Suite  B. 

b.  Solutions 


DoD  users 

will 

more 

than  likely  operate 

within  a 

hybrid  of  ECC  and 

RSA 

for 

the  near  term 

and 

into 

the 

foreseeable  future. 

The 

modular  nature 

of 

the 

PKI 

infrastructure  as  well  as  the  phased  implementation 
approach  will  drive  this  hybrid  solution  as  much  as  the 
fact  that  schedules  are  almost  certain  to  be  extended  to 
accommodate  delays.  Among  the  implications  of  this  hybrid 
approach  are  the  need  for  servers  that  can  support  both  ECC 
and  RSA. 

Web  servers  like  Fortitude  (Netscape  replacement) 
support  both  ECC  and  RSA  on  one  platform.  In  this  fashion, 
new  ECC  enabled  clients  can  still  talk  to  old  RSA-only 
clients  via  use  of  the  same  server.  Moreover,  this  will 
enable  a  smooth  transition  well  in  advance  of  any  final 
hard  RSA  cutoff. 
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VII.  CONCLUSIONS 


A.  INTRODUCTION 

Public  key  cryptography  has  become  a  mainstay  for 
secure  communications  over  the  Internet  and  throughout  many 
other  forms  of  communication.  It  provides  the  foundation 
for  key  management  and  digital  signatures.  With  key 
management,  it  is  used  to  distribute  the  secret  keys  used 
in  other  cryptographic  algorithms.  Regarding  digital 
signatures,  it  is  used  to  authenticate  the  origin  of  data 
and  protect  the  integrity  of  that  data.  It  is  paramount  to 
the  security  of  the  United  States  of  America  that  the 
information  deemed  too  sensitive  to  be  viewed  by 
antagonistic  entities  remains  secure.  It  is  from  this 
point  of  view  that  the  magnitude  of  the  implications  of  a 
failed  transition  to  new  cryptographic  techniques  is  fully 
realized. 

B.  FINDINGS 

The  Authors  of  this  thesis  have  attempted  to  determine 
some  of  the  potential  impacts  of  the  DoD  migration  to  NSA 
Suite  B  on  CAC  usage,  issuance  and  performance.  Testing 
was  divided  into  two  parts.  The  first  was  a  comparison  of 
1024-  and  2048-bit  RSA  key  generation  and  Secure  Sockets 
Layer  (SSL)  authentication,  including  detailed  statistical 
information  on  the  difference  between  the  1024-bit  keys  and 
the  2048-bit  keys.  We  found  a  significant  delta  in  key 
generation  times  from  RSA  1024  to  RSA  2048  although  there 
was  little  noticeable  difference  when  comparing  encryption 
and  decryption  times  and  digital  signature  generation 
times . 
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That  said,  if  the  DoD  continues  its  present  course  of 
action  of  further  increasing  RSA  key  lengths,  the  next 
iteration  will  be  3072  bits.  A  key  length  of  that  size 
would  be  unsustainable  in  terms  of  smart  card  issuance  for 
the  DoD,  given  that  2048-bit  keys  are  already  taking  nearly 
two  minutes  longer  to  generate  per  user  than  RSA  1024.  As 
noted  in  Chapter  IV,  the  relative  computational  performance 
advantages  of  ECC  over  RSA  are  compelling.  Prominent 
telecommunications  company.  Research  In  Motion,  has  also 
stated  publicly  that  the  key  pair  generation  for  RSA  3072 
is  "too  long"  even  for  their  platforms,  which  have  greater 
computing  resources  than  a  smart  card. 

Additionally,  based  on  findings  obtained  through  DMDC 
lab  testing  of  CAC  cards  using  different  RSA  key  lengths  as 
well  as  independent  private  sector  testing  of  ECC,  we 
assessed  that  Elliptic  Curve  Cryptography  will  provide 
comparable  security  with  more  efficient  performance  than 
the  first  generation  public  key  techniques  currently  in 
use.  From  this,  the  authors  have  determined  that  an 
attractive  course  of  action  is  to  implement  the  ECC 
alternative . 

The  authors  identified  and  attempted  to  mitigate  some 
of  the  risks  associated  with  a  DoD-wide  migration  to  NSA 
Suite  B.  We  identified  the  following  areas  as  potentially 
highly  risky:  intellectual  property,  software 
compatibility,  local  level  challenges,  resources,  funding, 
and  scheduling.  Unless  these  major  risks  are  attended  to, 
the  Suite  B  migration  project  will  be  in  jeopardy. 

Risk  mitigation  notwithstanding,  it  will  be  a  long 
while  before  the  U.S.  Government  will  be  able  to  completely 
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transition  to  a  new  cryptographic  suite  of  algorithms.  An 
RSA-ECC  hybrid  solution  is  more  likely  as  the  PKI 
infrastructure  slowly  adapts  to  its  changing  cryptographic 
environment.  In  fact,  the  phased  implementation  mentality 
that  has  so  far  defined  the  implementation  of  PKI  since  its 
inception  in  the  late  1990s  will  almost  certainly  demand  a 
parallel  solution  that  features  both  the  old  and  the  new 
for  quite  some  time. 

C.  SUGGESTIONS  FOR  FUTURE  RESEARCH 

As  was  alluded  to  in  Chapter  IV,  Smart  cards  that  are 
enabled  with  ECC  implementation  are  not  currently 
available.  When  they  are,  more  complete  testing  will  be 
possible.  This  testing  should  include  taking  a  measure  of 
on-card  performance  of  ECC.  Additionally,  more 
comprehensive  testing  of  end-to-end  ECC  performance  across 
DoD  networks  would  be  beneficial. 
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